Original subtitles

I'm about to take you from a complete

beginner to a pro cloud code user. Even

if you've never touched the tool before,

by the end of this video, you'll be able

to build automations, websites, apps,

[music] whatever you want. You'll even

have your very own AI executive

assistant. So, I have put a ton of time

into making sure that this course is as

comprehensive as possible, and I've laid

it out in the exact order that I would

have wanted to learn Cloud Code if I was

starting over. So, we've got 24

different chapters that are covered in

this course. Let's take a quick look.

I'm going to start off by telling you

guys about the shift in the Agentic AI

market and why you should be learning

Claude Code. I'm going to help you guys

get set up. We're going to go over the

cloud code operations. We're going to

talk about tokens and context when it

comes to just dealing with AI in

general. We're going to talk about

cloud.md. You're going to build your

first workflows. We're going to deploy

those automations so that they actually

can run 24/7. We'll talk about project

architecture, the built-in commands,

rag, building and deploying websites,

APIs, and MCPs. We'll take a look at the

Google CLI. I'll help you guys build

your very own executive assistant. Then

we're going to deep dive into skills,

sub agents, agent teams, browser

automations, permissions, context

management, GitHub work trees. We've got

some fun hacks for you guys and fun

things that you can do with cloud code.

And then finally talking about how you

can actually monetize this new

knowledge. So I don't want to waste any

time. Let's just get straight into the

course.

All right. All right. So, before I have

you guys open up Cloud Code and we start

getting our hands dirty, I just wanted

to sort of talk about the actual space

and what this shift means and why it's

so important. So, that's what we're

going to be covering in this section.

Check it out.

Aentic workflows are not just [music] a

trend. They're the future of the AI

industry. More and more companies are

making the shift to agentic workflows.

And this is just getting started because

it's estimated that the AI agentic

market is going from about $7 billion

this year to around 93 billion in the

next couple of years. So, I can tell you

right now that knowing how to build aic

workflows is going to be one of the most

valuable skills that you can have. So,

in this video, I'm going to break down

why you should be building aic workflows

and then I'm going to actually build one

live in front of you so you can see

exactly how it works. And by the end,

I'll show you how to actually sell these

if you want to make some money with your

skills. So, let's get into it. So,

before we build anything, I want to show

you why this all matters because it's

not just hype. This is real money moving

into real technology. Right now, the

Aentic AI market is sitting at around $8

billion. By 2030, that's expected to hit

40 to 50 billion. That's not just a

small jump. That's an entire industry

being built in front of our eyes. And

it's not just projections. About 25% of

enterprises are already deploying

Agentic pilots this year. And by 2027,

that number will jump to 50%. So half of

major companies will be running some

version of Agentic Workflows within the

next 2 years. And with that comes

massive budget allocations, new security

requirements, and a ton of new

opportunities for people who know how to

build these systems. So why is this

happening now? What's driving the shift?

It comes down to pretty much one thing

which is companies are starting to hit

that ceiling of what traditional

automation can do and they're starting

to realize they could move a lot faster

with more agentic workflows. If you've

been building workflows in tools like

end to end or Zapier, you know the

drill. You map out every step. You

connect the different nodes or blocks.

You handle the edge cases yourself and

it works until it breaks because

traditional workflows will break when

they hit something unexpected. And when

that happens, someone has to usually go

in manually and fix that. And that's

maintenance. That's time. That's

ultimately money. Now, I do want to be

real with you here because there's a lot

of noise online about a dentic workflows

that makes it sound like they're just

completely magic and they fix themselves

forever. And that is partially true, but

only in a specific context, at least

[music] right now. Cuz when you're

actively working in a tool like Claude

Code and you trigger a workflow yourself

and say, "Hey, go research these

competitors and build me a report." The

agent is sitting right there with you.

So, if something breaks, the agent can

catch it mid-run. It can adjust its

approach. It can update its tools and

keep going. That self-healing piece is

very, very real and it's incredibly

powerful while you're building and while

you're iterating. But once you deploy

that workflow to run on its own on a

schedule or triggered by a web hook or

something like that, that is when you're

deploying the code, you're deploying the

tools, not the actual agent itself. So

if you've seen my previous videos where

we've used the WAT framework, we are

basically deploying the W workflows and

the T tools, but not the A agent. But

I'll cover this more in depth later

during the live build if you're

confused. But what this means is that

the self-healing ability ultimately goes

away when the code is up in the cloud,

you know, running automatically. And at

that point, it does behave more like a

traditional automation. But that's

really a good thing because automations

are predictable. They're deterministic.

And those types are the best ones. So

then where's the real advantage? Really,

it sits in how you build. Traditional

automation is like building a train

track by hand. You're laying every rail,

every switch, every connection all by

yourself. Whereas with aentic workflows,

it's like you're just telling a

construction crew, "Hey, I need you to

build a train track from here to there."

And then they build it for you. Meaning,

if they hit a problem during

construction, they would figure it out.

So you end up with a better train track.

It's built faster with fewer mistakes

because the agent handled the edge cases

during the build process that you might

have missed or not thought of. And then

the idea is you battle test it before

you ever actually deploy it. So then you

have a lot of confidence that it will

always work. So in our train analogy,

before we deploy that train track, we

would have like 10 different types of

trains test drive on it. They would be

different weights, different lengths,

and maybe different wheels. And we'd

want to make sure that our track can

work for all different types of trains

before we deploy it. And the reason this

is actually possible now is because the

technology has finally caught up. LM

have gotten really reliable enough to

use in production and we're not just

playing around with chatbots anymore.

These models can reason, they can make

decisions and they can execute

multi-step tasks with real consistency.

On top of that, we've got things to use

like skills or MCP or aa. We've also got

infrastructure like trigger.dev, modal

or versell that make deployment way

simpler than it used to be. And most

importantly, we've got tools like cloud

code that make all of this accessible to

non-developers. So, we can see that the

market is absolutely shifting towards

aic systems and the numbers back it up.

But here's a question that's probably on

your mind. Does this mean everything

that I've learned about Naden or

traditional automation is useless? Not

even close. And let me explain why. The

people who are going to struggle with

agentic workflows are the ones who

completely skip those fundamentals and

jump straight into cloud code, tell it

to build something, and have no idea if

what is being built is actually good.

They probably don't know what a web hook

is or how APIs work. They won't be able

to spot when the agent made a bad

decision because they've never built the

thing manually themselves. Now, that's

not to say that a beginner can't learn

cloud code. And because you actually

understand how automations work under

the hood, you can communicate precisely

what you want much clearer. And you'll

see once we hop into the live build just

how important it is to actually be able

to communicate really clearly. All

right, so now you understand why agentic

workflows are such a big deal. Now I'm

going to show you how simple it is to

build an agentic workflow using cloud

code. And by the way, if you want to

follow along with what I'm about to

build, you can grab all the resources

and files that you need completely for

free in my free school community. The

link for that is down in the

description. All right, so we're now in

Visual Studio Code, which is where we're

going to actually use Cloud Code. Visual

Studio Code is just an IDE or an

integrated development environment. And

that's where, like I said, we're going

to be using Cloud Code. So, if you don't

have this up and running yet, all you

have to do is go to a browser and type

in Visual Studio Code and download the

right one for your operating system. And

then once you open that up, it should

look like this. The first thing you have

to do is install the Cloud Code

extension. So, you're going to go over

here to the lefth hand side. You're

going to open up extensions. And then

you will see right here cloud code. Or

if you don't, you will search Cloud

Code. And once you pull that open, it'll

ask you to install it. And then once you

do, it'll basically just prompt you to

sign in with your Claude subscription.

Now, you do have to be on a paid plan

for Claude in order to access Cloud

Code. As you can see on the free

version, you don't get Claude Code, but

right here on the paid version, you do.

So, you can start off with the pro plan

at 17 bucks a month. And then, if you

need to, if you keep hitting limits, you

can upgrade to max, which honestly, you

probably will. I'm on the max plan, and

it is an amazing return on my

investment. So, I would just go with the

max. But anyways, you'll get

authenticated, and then it will bring

you back here. And now we can actually

get going using cloud code and building

workflows. So I'm going to close out of

this screen. And what we're going to do

now is we're going to open up a project.

So on this lefth hand side, I'm going to

go up here to explore. And this says you

have not yet opened a folder. Open a

folder. So essentially when we're in

cloud code, we're going to be working

within a certain folder. And that's kind

of the way that I think of like this is

the project that we're working on. So

I'm going to click open folder and I'm

going to open up a blank project. So you

can see I'm in a folder called

newsletters demo. And there's nothing in

it. It's completely fresh. I'm going to

click select folder. And now we can see

we're in this project. I'm real quick

just going to close out of this and

close out of this just so we have a

really clean interface to look at with

not much going on and I can explain what

we're actually about to do. So to make

this as simple as possible in cloud code

we have an agent and we have files.

That's it. The lefth hand side is where

we see those files. We'll see different

workflows. We'll see tools. We'll see

all these little things. And then on the

right hand side we'll have the cloud

code agent and that's where we talk to

it. We plan with it. It asks us

questions and it actually executes and

writes the code or builds the workflow

for us. So, if I switch back into Visual

Studio Code and I double click right

here and then I open up this button that

says Claude Code, this is where we

actually open up the actual Claude Code

agent right there. So, I'll close out of

this. You can see this is kind of what

we're talking about now. Files on this

side. There's nothing there yet. And the

Claude Code agent right here. Now, what

we have to do next is give Claude Code a

cla.md file, which is basically just

instructions for this specific project.

And you can really just think of this as

a system prompt. So that way when we the

user send a message to our cloud code

agent, it doesn't just process what we

said and respond to us, but it also

every time reads the claw.md file. So

this is where you're going to put

important things like how the folders

are laid out. You know where to find

your different files, what its end goal

is, any frameworks that you might be

using. So in this case, what we're going

to be doing is we're going to be using a

framework called WAT, which stands for

workflows, agent, and tools. So, real

quick, if you pop over to my free

community and you go to the classroom

and then you click on cloud code right

here, you'll see the watclaw.mmd and you

can go ahead and download this file

right here. And once you've downloaded

that file, you can actually just drag it

over here to the lefth hand side and it

should pop up as cloud.md. And if you

wanted to, you could read through this

entire basically system prompt to see

what I'm telling it about how to build

workflows, how to build tools, how to

keep learning and how to, you know, set

up its its folders and everything. But

I'm not going to read that all out right

now. What I'm going to do is just

basically tell Claude Code to set up the

project. read the claw.mmd file and then

set up the project and the structure and

then we'll start building workflows

together. So I'm basically just going to

shoot that off and it's going to go

ahead and read that and get everything

ready. So we'll see soon on the lefth

hand side we've got all our different

folders set up. But while it's going

through and doing that let me just

explain what these different things are.

So agent that is the actual cloud code

agent that we just talked to as you saw

and the agent utilizes workflows and

tools to help us automate things. So the

first thing is workflows. These are

markdown files which you just saw

similar to the cloudMD and it looks like

this. It's basically completely natural

language. You could read through every

line and understand exactly what's going

on. It just uses things like pound signs

and, you know, dashes and asterisks to

separate like what's a header and what's

bold to stress importance for the agent.

Workflows are natural language

processes, instructions. So, right now,

let's just use an analogy of a recipe.

The workflow is the recipe. So, you'd

have a workflow for how to bake a

chocolate cake. And when you want to

bake that chocolate cake, it's going to

tell you what to do in certain order.

So, it's going to say, "Preheat the oven

to this. Boil some water." I don't know

why you'd boil water for a cake. Crack

two eggs in a bowl, you know, measure

out a cup of flour, whatever it is. And

those are the tools. So, the tools are

all of the ingredients, but without the

structure of the workflow, saying use

tool one, then tool 5, then tool 7, then

tool 10. Without the order and the

structure, the tools are useless. So,

basically, the workflows tell the agent

how to build the tools. And what's

really cool about both of these is as

they're being built and as they're being

used, the agent will improve them over

time if it makes mistakes or if it

learns things. So that is why we use the

WAT framework to build our workflows

with cloud code. So now that that's

done, you can see that this is finished

up and it's basically said, okay, the

project is set up. Here's a summary of

the structure. Here's what I understand.

We're going to be building workflows in

this project likely around newsletter

operations. WAT framework. I will act as

the agent. I will read workflows. I will

run tools. I will handle errors and

improve the system. I've got Python

ready to go. And I'm going to store

secrets in thev. So this is where we're

going to put our API keys rather than

putting them straight into claw so that

they could be exposed who knows where.

Okay. So, what I'm going to do is go

ahead and do a /cle just to get rid of

this conversation and we can start

fresh. And we're going to start to plan

out this workflow that we want to build.

Before we start planning, I'm going to

switch this to plan mode. So, you can

see we're in bypass permissions. You can

go to ask before edits. You can go to

edit automatically. But I want to go to

plan mode. And it's really, really

important, as we talked about earlier,

to be able to communicate clearly what

you want. And the cool thing about Cloud

Code is when we give it a plan, even if

it's pretty ambiguous, it will come back

and say, "Okay, in order for this to be

good, I need to know X, Y, and Z." So,

I'm going to give it a fairly ambiguous

prompt here. And then you're going to

see it ask us questions and plan out

this workflow for us. Hey Claude, I want

to build a workflow which will basically

be a newsletter automation. I want to be

able to tell you that I need a

newsletter about a certain topic and you

will do research. You will structure it

in HTML. You will make it look pretty

and you will also create a few

infographics to go with it. So help me

figure out what text stack to use here

and what else you might suggest that I

haven't yet thought of. So I'm going to

shoot that off. Now, whether we're in

plan mode or, you know, bypass

permissions, what happens is the agent

starts thinking and it starts testing

things out. So, it's thinking, it's

reading through files, it has this

little thing that will say computing or

deciphering or wobbling or whatever it

is, just a bunch of little silly words.

Um, but that just basically shows you

exactly what it's doing. All right, so

we're just at the point where it's

asking us some questions before it

continues working on the plan. The first

thing is for research, do you want to

add an external search API to pull in

data? So, what I'm going to do is say,

yeah, sure. Let's just go ahead and do

perplexity. for delivery. It asks us if

we want to use Beehive or if we just

want to send the HTML file for now. I'm

actually just going to go ahead and say

let's actually just send this over in

Gmail. And now it asks us about brand

assets, which is really cool. So, if we

want to, we can send over some brand

guidelines or logos and stuff like that

to make sure that the newsletters are

always formatted and they feel on brand.

So, I'm going to go ahead and say yes, I

will provide some brand assets. So, then

what happens is it comes back with a

final plan. Let me just zoom out a

little bit so we can actually see that a

little bit better. We'll go ahead and

see what it came up with. So, newsletter

automation workflow. We want to conduct

research, generate HTML with polished

visual design, create infographics to

accompany the content. We've got a

research layer. We've got the content

generation. We got the infographics. So,

it says that it could use data stats

infographics or it could use SVG. Why

not image generation? It's too

unpredictable. It can't embed. I'm

actually going to go ahead and say that

I wanted to use nanobanana. So, I'm

going to go ahead and type in here for

the infographics. I want you to generate

AI images using nano banana. You can use

a platform called key.ai. So this just

shows the importance of plan mode and

reading through the plan so that you can

make sure before it actually starts

building everything you like what it's

going to do. Okay. So now that new plan

has been done you can see the text stack

is going to be research with perplexity.

The content will be written with claude.

The infographics will be created with

nano banana. We will write the email in

HTML and then send that via Gmail. And

it even comes up with a section here

about things the user likely hasn't

considered. So things like human review,

subject line, metadata, brand

consistency, all this type of stuff.

Now, the last thing that I actually

forgot to give it was my brand assets.

So, what I'm going to do real quick

before we accept or, you know, keep

working on the plan, I'm going to create

a new folder over here. I'm going to

call this brand_assets.

And you can see I dragged in two things.

I dragged in AISPG, which is our logo,

and I dragged in our brand guidelines.

So, I want the newsletter to be

formatted in this way. So, I'm going to

click on no key planning, and I'm going

to tell Claude that it needs to use

those two assets. So, what's cool is

that I can actually directly tag them.

So I'm saying make sure the whole

newsletter is branded based on my logo

and brand guidelines. So for logo I'm

going to do at and I'm going to type in

AIS. You can see that it's going to show

AIS PNG. And then here I can do at AIS

and I'm going to click on brand

guidelines. So now it's going to look at

those exact two things and it's going to

be able to make sure that the newsletter

is branded. Okay. So this time the plan

looks good to go and I'm just going to

go ahead and auto accept and I'm going

to turn on bypass permissions. So it's

going to build everything out. It's

going to put the different files that we

need and then we should be able to

basically just add our API keys and then

test it. So, what it's doing now is it

creates a to-do list. So, this is all of

the things that it has to do and as it

actually completes them, it crosses them

out. So, it's really cool because you

can work on something else on a

different screen and just kind of check

in on cloud code to see where it's at

and if it needs any help. Now, you guys

may be wondering about this bypass

permissions mode. If you don't see this,

you just have to go to your settings. In

your settings, search for cloud code.

And then right here, you'll be able to

see allow dangerously skip permissions,

which turns on allow bypass permissions

mode. Okay, so that is finished up. It's

telling us here's what it built. So it

created two config files which we can

see right here. It's got newsletter

style which basically just shows like

the colors and the text and the

background and it's got recipients which

is where we need to add who this is

actually being sent to. So this is where

we would add a huge list of you know our

email list basically. Then it created 1

2 3 4 five different tools. If I open up

those right here the tools are research,

generate infographic, assemble HTML,

send via Gmail and archive to sheets.

And here is what all of those five tools

do. And then of course we have the

actual workflow right here which is our

markdown file which basically shows step

by step how to actually build the

newsletter and what tools to use. And

this is the complete natural language

just explaining the process. So now that

those have all been created the last

thing that we have to do before we

actually test it out is we have to give

it credentials. So anthropic perplexity

key.ai and then our Gmail. So what I'd

do is I go to Plexity grab my API key. I

would come into thev and then over here

it's created these placeholders. So all

that I have to do is paste in my API key

right there and then hit save to make

sure that all this saves. So I'm going

to go ahead and do this now for my other

API keys. Okay, so we've done everything

that it told us to do. We've set up all

our credentials. At least I hope we

have. If we run into any errors, Cloud

Code should fix it or tell us what to

do. What I'm going to do now is just

kick off a prompt. Write me a newsletter

about Aentic AI. So I literally just

said, write me a newsletter about Aentic

AI. And that's it. What it's doing now

is it's looking through the relevant

workflows and tools, and it's going to

figure out what to do. Here you can see

it said, "I found the newsletter

workflow. Starting with step one, I'm

going to do some research." You can see

after that it's going to plan and

generate the infographics. It's going to

write the newsletter content and then we

actually have a human review point. So

it's going to get subject line approval

and then if it's approved, it'll go

ahead and send the newsletter. So now

your job at this point is just to watch

it and to make sure it's doing

everything right. And if it runs into

issues, it should fix itself. But

sometimes it may need you to help steer

it in the right direction. The first

test run is the only one where it's

really like this because you have to see

how it works. But then after that, you

should be able to just trust that it's

going to run pretty much perfectly every

time. Here you can see we've already run

into our first issue. There was a unic

code encoding issue, but it's just going

to go ahead and fix it. And that's great

because I don't really know what this

means at all. So I'm glad that it

understands what to do. Nice. So you can

see it planned out three infographics.

It's got a market growth. It's got

Gartner road map and it's got impact

metrics. So here's a good example. It

was trying to generate those

infographics using key.AI, and it was

getting an error. So what it did is it

looked into the problem. It said, "Let

me investigate to find the correct

endpoint." It did some web searching. It

looked through the docs. It did multiple

searches as you can see. And it figured

out that the endpoints have changed. And

now it's able to switch the tool so that

it works this time. There we go. So, it

said, "I found the fix. Here's the right

endpoint. Let me update the tool so that

this doesn't happen again." And now it

just went ahead and fixed the tool. All

right. At this point, it did a human

review step. And we could obviously say

we don't want this if we don't want it.

But for now, let's just go ahead and see

what it wants. It wants us to approve a

subject line. It asks us to choose which

one. I'll go ahead and send five. And

then we will see the final output. Okay.

So, a few things happened and I'm

actually glad they did so I can show you

how you need to troubleshoot this. So,

the first thing is we got the email, but

the HTML is all messed up. It came

through with a background color, but

then all of this just is horrible. So,

we're going to have it fix this. The

second thing is I gave it the wrong

Google sheet ID to archive to sheets

because there was some sort of access

issue. So, I'm going to go ahead and fix

that sheet ID and I'm just going to use

my natural language to tell it that this

is horrible. I've updated the sheet ID.

However, the actual email that I

received is completely awful. I can't

read any of it. It doesn't even make any

sense. take a look at figure out what

happened and try to send me it again.

So, it's going to go ahead and diagnose

what happened and then hopefully send us

a better version. So, once again, it

found the issue. It found out exactly

how to fix it and now it's updating the

workflow in the tool so it doesn't

happen again. Now, of course, cloud

code's not perfect. You guys can see

that in this demo, but think about if

you were doing this in something else

like ended or something that's a bit

more manual and you were running into

these issues and you'd have to go back

and fix all of the logic yourself and

try to debug all this. I've literally

just been telling it to fix it and then

like doing other work or going in the

other room and waiting for it to figure

it out on its own. Okay, now it fixed

everything. And if I go over to my

email, we see this newsletter. What

happens when AI stops waiting for

instructions? We can see that we've got

our logo up top. We've got AIS

intelligence brief. It does think that

it's June 2026, which is wrong, but we

could obviously fix that very easily.

But now we move into the actual

newsletter. And keep in mind, this

started with one prompt that said,

"Write me a newsletter about Aentkai."

That was it. Also, throughout the

newsletter, pay attention to the fact

that it's using our fonts. It's using

our brand guidelines, our colors, all of

that in this newsletter. So, the first

section is about the market landscape,

an explosion that cannot be ignored. I'm

not going to go ahead and read all of

this text. It would just take too long.

A nanobanana AI generated image with

text with graphics. And this infographic

is also adhering to our brand

guidelines. In section two, we have

architecture. We've got a little bit of

a quote here. And if we keep scrolling

down, we've got some more statistics.

We've got section three. We've got

another quote. And we have another

infographic. Once again, adhering to our

brand guidelines and using a little logo

up here as well. And that's pretty much

how the rest of the newsletter goes.

We've got section four. And we can see

our third and final infographic that has

a different version of the AIS logo as

well as our brand guidelines. So this

was literally iteration one. There's a

lot of things that we can improve here.

And all we would do is we'd open up

Cloud Code and we'd ask it to make it

better using natural language. We could

actually make sure that every

infographic it creates uses our actual

logo rather than prompting some sort of

AIS logo in there. It ends with some key

takeaways and then we have it ends with

some key takeaways. We have a call to

action down here and then all of the

sources we could actually click on and

it would take us to that actual site

where it pulled the data from. So that

was version one of the newsletter and I

think that that's pretty solid. Now the

cool thing about these projects in cloud

code is as you use them more they get

better and better because every time I

run this workflow it might find

something else out and it will update

its cloud MD, it'll update its

workflows. It'll update its tools. As I

give it more brand asset, as I give it

more context and more knowledge, it just

gets better and better. And then once

you really trust the actual workflows

and tools, that's when you go ahead and

you come back into this. And then once

you really trust the workflows and the

tools that you've created using cloud

code, you would basically take these two

things and you would push those into

like a GitHub repository and you'd sync

those to something like trigger.dev or

modal in order to actually have them run

every single Monday at 6 a.m. or daily,

something like that. I'm not going to

dive into that in this video, but if you

want to see one where I did, then I'll

tag one right up here. So, what you guys

just saw here was me using hardly any

prompting, just using my natural

language, giving it a few logos and

colors, and then giving us a really,

really good output for a newsletter.

Now, one thing that we didn't cover in

this video, but we will be covering a

lot more in the future, is how you could

actually make your workflows even better

and better, and that's the idea of using

skills. Whether it is a skill that you

create yourself or whether it's a skill

that someone else has already built. So,

skills are basically just system prompts

that you could load in when you need

them. So, let's say you ask Cloud for

help. Hey, can you design me a website?

The agent will then check through all of

the skills it has access to and it will

see based on all of these skills, does

my current request require this? So,

it's almost like the same way it decides

if it should use a tool or not. So, for

example, there is a front-end design

skill that makes Claude Code so much

better at designing websites. And so, if

I'm ever building a project where I need

it to be able to build websites, I would

tell it to always invoke the front-end

design skill. And the reason I'm

bringing this up is because you can

create your own. So, what I might do in

this version is once I realize what I

really like about how it creates

newsletters, I will tell it to turn that

into a skill. So maybe it is the skill

of making infographics look really

really polished with the AIS logo in the

top left corner and I could create that

skill so that every time it needs to

create a new infographic it reads that

first and then it makes its outputs a

lot more consistent. So I know that this

seems a little bit intimidating at first

but hopefully you guys realize after

watching this how easy it was for me to

actually do this once again with hardly

any technical knowledge. We didn't set

up any API calls. We didn't do anything

like that. We just talked to it. But now

the question is how do you actually turn

a skill like this into income? So this

is something that I see all the time. a

business owner watches your YouTube

videos or LinkedIn posts or whatever it

is and sees flashy AI demo. Maybe that's

a voice agent or a really cool chatbot

or a crazy looking dashboard and they

come to you or some sort of like, you

know, AI agency and they say, "I want

that." But when you actually sit down

and you look at their business and their

operations, that's not what they need at

all. The real problem is that leads

might be falling through the cracks or

the onboarding is taking way too long or

there's tons of manual data entry going

on. Just think about it like plumbing.

If you have a pipe that's clogged, it

doesn't matter how much water you pour

into it, it's not going to flow any

faster if there's a clog. Most

businesses are out here trying to put as

much water into the pipe as possible,

hiring more people, throwing AI at

random problems. But what they actually

need is someone who can come in, find

the clog, and then clear that, and then

start to add more water in. That's

really the skill. And if you can cut

through the noise and identify real

constraints and unclog that pipe, that's

worth way more than building some super

flashy agent that looks cool, but

doesn't actually move the needle. The

build itself is also not what businesses

are paying for because building is

getting easier and easier every day,

which is good news, but it also kind of

brings about some panic because more

people can spin up these automations

much quicker and that's becoming a

little bit more commoditized. So, if

you're trying to compete on I can build

AI automations, you're going to be in a

race to the bottom. What you need to do

is act as the doctor, not the

pharmacist. I've used this analogy a lot

on my channel. A pharmacist just fills a

prescription that someone else wrote,

but a doctor sits down with the patient,

asks questions, runs diagnostics, and

figures out what's actually wrong before

anything is then prescribed. That's the

difference between someone who just

builds workflows and someone that

businesses will pay serious money to

work with. So, when you're talking to a

business owner, you're not leading with

I build aic workflows in cloud code.

They don't care about that. You're

leading with I can save you x amount of

time per month. You're leading with I

can save this process x percentage of

errors. And that's exactly why you

should not be pricing yourself hourly.

Because if you can build something in 30

minutes, that ends up saving the

business, let's just say, 20 hours a

week, that's not a 30-minute job. That's

tens of thousands of dollars in value

over the course of a year. So if you

price yourself at an hourly rate, you're

putting a ceiling on your income and

you're completely ignoring the value

that you're actually delivering. Now,

hourly can be fine early on when you're

just getting started and you're building

trust and you need to get your first few

wins. But once you can clearly show the

ROI, the hours saved, the cost

eliminated, the revenue generated, all

that kind of stuff, then your pricing

should really be reflecting that value,

not your time. Trading time for money is

not very scalable. So, here's a simple

way to think about it. You sit down with

a client and you figure out their

processes, and you calculate that this

system is going to save them $10,000 a

month. Now, let's say you charge $5,000

for that build. That should be a

no-brainer for them. They make their

money back in 2 weeks, and then

everything else is just profit for the

business. And it's also a great deal for

you because that build might just have

taken you a few days, maybe a few weeks.

That is basically valuebased pricing.

Everybody wins. Now, in terms of

actually finding clients, I've done a

full deep dive on that in another video,

which I will go ahead and link right up

here. But at a high level, the approach

is simple. You don't need a huge

audience. You don't need to start a

full-blown agency. You just need to

start conversations with the right

people. You need to be transparent about

what you're building and lead with how

you can help them. Once you deliver the

solution, you stick around because once

that first system is running and they

see the results, they're going to want

more. They're going to want you to

optimize the build. They're going to

want you to expand on it. They're going

to want you to help find new

opportunities inside their business.

That's how a $3,000 build turns into a

$50,000 a year relationship. But the key

there is that you have to be the one to

track the metrics. You have to take

ownership over that. You have to

practively show them the value that the

system is actually adding. That's super

super important. And that's exactly the

path freelancer to consultant to trusted

partner. You're not just building

workflows. You're becoming the person

businesses rely on to make their

operations smarter. So we just went from

understanding what's happening in the

agentic workflow market to actually

building one live and seeing how to sell

these systems for premium prices. Here's

the thing though. This isn't just the

future of automation. It's happening

right now. Companies are already making

the shift and the demand for people who

can build these systems is only going to

grow. So, if you want to dive deeper

into this kind of stuff, I've got a

community with over a quarter million

members where I share templates,

resources, and all the files from videos

just like this one.

Okay, so now we're going to start to get

into it a little bit. So, the first

thing I want to talk to you guys about

is the different ways that you can

actually use Cloud Code so that I can

help you figure out which way is best

for you. And then we're going to move

into some foundational concepts like

prompting, AI models, you know, tokens,

context, windows, cloud.mmd, what does

all that stuff mean. So that's what

we've got coming in this chapter.

One of the most common questions I've

been getting lately is where should I be

running cloud code? Whether that's in

anti-gravity or VS Code or desktop app

or in the terminal. And it's important

to understand that they're all a little

bit different, but they're all a little

bit the same. So in this video, I'm

going to break down the five best

methods. For each of those, I'm going to

show you what it looks like, what it

does, the pros and cons, how you can get

it set up, and who it's actually for, so

that by the end of this video, you'll

100% know which way that you should be

running Claude Code. So, let's not waste

any time and get straight into number

one. All right, so number one, we have

running Claude Code in the terminal.

When you run in the terminal, this is

typically what it looks like. And it may

feel a little bit more intimidating if

you've never used the terminal before,

but it's important to understand that

this is the foundation. So, even if you

never used this directly, you need to

understand that this exists because it's

kind of the core. You open the terminal,

you type in Claude, and then you

instantly have Claude right there, and

you start chatting. It can read the

files. It can edit the folders that

you're in and do work like Cloud Code

should. Everything though is pretty much

text. There's no buttons. There's no

menus. It's not very visual. It's just

text. It is a CLI. And the engine that

powers this, every other Surface uses as

well. So, the desktop app, the VS Code

extension, they're all wrapping around

the same engine. And moving on to pros

and cons. The pros are that you have the

most control. So running in the

terminal, you're going to have the most

amount of commands and the most amount

of like hackability. A lot of times also

features are coming first to the

terminal and it works with any editor

because it just needs a terminal window,

which means if I'm using something like

VS Code, I can use the extension if I

want something more graphical and I can

use the terminal in there if I want more

power. The cons are that it's text only.

So it's sometimes not great to

understand like what's going on behind

the scenes or what's going on with your

files and folders and a bit of a steeper

learning curve if you're not comfortable

in a terminal. For instance, I don't

love working in the terminal, but now I

can do it and I understand it and

sometimes I have to. So, who is this

for? For people that already live in the

terminal. They understand it. This is

their home. If the word terminal makes

you nervous, then just keep watching

because there are other options that let

you use cloud code and still achieve the

power you need. So, real quick, I just

wanted to show you what this could look

like. I'm opening up my terminal that's

going to pop up right here. You can see

that right now I am in my kind of home

directory in Nate H. If I wanted to get

into a different project, I would just

need to do a CD to switch into that

folder. And so that's what I mean by

command line interface. We switch into a

folder with text rather than if I pulled

up like my actual file explorer rather

than being able to just switch folders

over here or clicking on different

buttons. So that's kind of the

difference between a GUI and a CLI. But

all you have to do to install it is go

to cloud code docs and you can see this

quick start and it basically just says

make sure you have this stuff. And so

you do need a paid cloud subscription.

So either the pro, max, teams or

enterprise. And then you basically just

have to run one command. So whether

you're Mac OS, Linux, Windows

PowerShell, Windows command line, you

just run this command and then it will

take you through some onboarding. So it

will say, "Hey, can you please log into

your account? Can you do this? Can you

acknowledge that this is blah blah

blah?" And here's where you can see you

basically would CD into your project.

And then all you have to do is open up

your terminal and type in Claude. And

now after I trust this workspace, I have

Claude and I can say hello and I can

talk to it the same way that I would in

anything else. I can hit question mark

to see the shortcuts. I can start doing

slash commands if I want and see front

end design skill or I can change the

model or I can even do something like

ultrathink which you can't really see in

other ways. And like I said, it just has

the most power because I can also do

something like customizing my status

line, which means that I could basically

customize what I see down here. So I

could see the cloud info like model

name, context usage, or I could even

describe other information that I want

to see about this session. And then if I

want to exit out the session, I can just

hit C twice and cloud code has now been

terminated. And now moving on to number

two, we have the desktop app. So this is

what it looks like. In the desktop app,

you have chat, you have co-work, and you

have code. So if you're already using

the desktop app for these things, then

you're probably really used to the way

that this looks and feels. And you also

get a cool little animated crab that

will do funny things right there. So

this is a visual GUI first experience

for people who don't want to touch a

terminal. It's the same cloud code

engine, of course, but it's just wrapped

in a different type of interface with

buttons and panels and visual feedback.

So you basically just Google, how do I

install cloud desktop? It's going to go

over some system requirements and then

you go to the downloads page and then

you basically just go through the setup

in order to actually download this for

your operating system. So, what are the

pros and cons? Well, we have visual

differences because you can see the

changes that Claude made line by line

and accept to reject them. It's just a

bit easier to actually tell what's going

on in my mind. They also have a really

cool built-in app preview. So, in the

desktop version, if you're building an

app or something like that, it'll start

up the dev server and you can see it

right in the app itself, which is kind

of a cool little feature. You can have

multiple sessions running in parallel,

which you can do in all of these, but

it's just a little bit different because

these get isolated in their own branch

and you can click through them pretty

easily. And it probably is the easiest

and least intimidating for non- terminal

type of people. And you still get the

same local file access. Now, for the

cons, this is a bit more of a manage

experience. It's less customizable. It's

less hackable. The desktop releases can

sometimes lag behind the CLI. And right

now, it's just Mac and Windows only.

Okay. So, here is typical Claude that

you would see, but I've got chat, I've

got co-work, and then I've also got

Claude code. And so, this is what it

looks like in the desktop app. You can

see that we still have our same

conversation feel. Up in the top right

is where you can see we could start our

actual preview if we have, you know,

some sort of app that we're building or

a website. But something else that we

get in Cloud Code is that we get our

scheduled tasks. And that's a really

cool native feature that will run

whenever we have this desktop app open.

And we can have tasks scheduled for once

a week, once a day, whatever we want. We

also have the ability to kind of look at

what we have for customization. So in

this project, we can look at our

connectors and our skills. And here's,

like I said, the crab does some funny

things every once in a while. You can

change your chat model down here. You

can still use different slash commands.

As you can see, we've got access to all

of these different commands. But there

are probably some where you might try to

invoke them. Like let's try if we try to

use agents. And as you can see, I don't

think it did anything. But if I open up

the terminal and I do / aents, we have

this actual command which lets us create

new ones or you know play with other

ones that we've already built in this

project. So who is this for? This is if

you want the power of cloud code but you

like clicking buttons instead of typing

commands. It's a really good place to

start especially if you've already been

using co-work and you want to start

dabbling with cloud code. But just stay

tuned because you might also like option

four which is what I use every single

day. And now moving on to number three

we have the web. Now, this is a research

preview, an experimental type of

product, but it is pretty cool that you

can access this on the web, so you could

use it from your phone. So, there's no

local setup needed, which is really

nice. And it runs entirely on the cloud.

So, you go to claw.ai, you open the code

service, you connect your GitHub repo,

and that's what it uses. So, it

basically clones into your repo in a

cloud environment, and it will do all

the work for you. So, it can still

manage those files and folders. You

review the changes, and then you can

create a pull request, and you can do

all of that from your browser. And a big

deal here is that it keeps running even

if you actually turn off your computer

because it's running on Anthropics cloud

environment. So pros and cons, we've got

almost no local setup, just a browser,

just to add a GitHub account. It works

from any device, whatever you need.

Sessions persist, so Cloud keeps working

while you're away, and it's great for

kicking off long tasks and checking back

later. So Boris Churnney, the guy who

created Claude Code, did a tweet about

how he actually uses it. And what he

said here is that he runs five clouds in

parallel in his terminal and he also

runs five to 10 on claw.ai/code. So in

the web. So really that's just to say

that you don't have to use just one and

stick to just one. But it's important to

understand the differences. So right

here you can see that I'm at

claw.ai/code. I could here connect a

GitHub repository as you can see. I

could choose that over right here as

well. I could be in testing or a

different environment and I could start

all my sessions off right here and then

they would keep running. So you can see

here I just started a new session. I'm

actually not even in any repo right now.

and I said hello. And you can see that

it's going to give you a very similar

feel to the desktop app version with our

sessions on the left and then kind of

our chat interface right here. So, who

is this for? If you want to hand claw a

task and walk away or if you want to

code from your iPad. But of course, you

could also use that new feature which

was the remote control. So, you can kind

of see how these all kind of blend

together. They're similar, but they're

different. All right, let's move on to

number four, which is idees. And this

has also caused a lot of confusion

because there's multiple different IDEs

out there. So this image right here is

how I use it in Visual Studio Code. An

IDE stands for integrated development

environment and it's basically just a

GUI for editing files and folders. So VS

Code is an IDE. Cursor is an IDE.

Anti-gravity is an ID. I don't know why

I have cursor twice right here. But

those are all IDEs, which is why I said

that this has caused some confusion cuz

people are like, why would you use this

in VS Code over cursor or over

anti-gravity? And then anti-gravity has

its own agents. So people get confused

about that too. But they're all just

code editors. And Cloud Code has an

extension that allows us to run Cloud

Code inside of them. And I like it

because I can see the files that I'm

looking at. And Cloud can see what I've

highlighted and I can see my project

structure and my folders and files. I

can drop things in and I can reorganize

it. Now, some of these IDs do have their

own built-in agents, which is why it

might get a little weird because

anti-gravity has some Gemini agents.

Cursor has its own. VS Code even has its

own agents, too. And there's lots of

other extensions and different ways that

you can customize your IDE. All right.

Right. So, starting with the pros, we

have zero context switching because

Claude can see exactly what you see in

the editor. You can also review changes

using your editor's built-in tools,

which is really nice. You have really

quick access to opening up different

sessions and using keyboard shortcuts.

And like I said, I just feel very

productive in there. And it also works

in multiple IDEs as far as the cloud

code extension. So, you can pick

whichever editor that you prefer. Now,

some of the cons are similar to some of

the cons on the other ones. You don't

get some of the advanced features that

are CLI only, but I'm going to show you

guys why that's not a big deal at all.

Your experience is also tied to the

performance of the editor. So if VS Code

is slow or it's crashing, then that's

going to make Cloud Code feel like it's

crashing. But really, it's just your

IDE. And each IDE has its own agent,

which can be a little bit confusing. But

if you're just using the Cloud Code

extension, then it's not too bad at all.

So when you open up VS Code, which is

free to download, or anti-gravity or

cursor, this is what it looks like. And

you can basically open files, you can go

into folders, you can clone a GitHub

repo. But where the magic really comes

in is when you go over to the lefth hand

side and you open up your extensions.

And this is where you would search for

claude code for VS Code and you would

install this. And this basically pops up

a little button in the top right which

says cloud code. And when I click on

that now I have the ability to actually

talk to a cloud code agent. And then it

also gets pretty powerful because

there's tons of other extensions you can

use. So then when you actually open up a

project it's really nice because you can

see all of the folders and all of the

files over here. And not only can you

see them here, but you can open them up.

So, if I click on my cloud MD, I could

go ahead and read this right here as

markdown. I can also see that these are

new lines because they're green. And I

can see over here that all of the things

that are green or yellow haven't been

yet pushed to my GitHub because they're

either new or they have been edited. So,

that visually helps me a ton. Also, when

Cloud Code is making a plan, so in this

session, I had it build a random plan.

It pops that out right here as text. And

what I can do is I can leave comments on

specific elements if I want to correct

it or have it, you know, fix some

things. And we all know the importance

of planning. So, this really helps me be

able to make the plans better so that

the automations or the skills end up

being better in the end. Now, we also

have some status indicators. So, at the

top of this window, if we see that

there's a blue dot, it means that

Claude's waiting for us. And over here,

if there's an orange dot, it means that

Claude has finished up. If I want to, I

can also have multiple different

sessions running in different little

areas. So, I could have, you know, split

pane view where I have four windows and

I can talk to all four agents. And then

finally, we talked about how sometimes

we need some features that don't allow

us to work in VS Code. So, for example,

if I try to run the / agents command

right here, it says, hey, you need to do

this in the terminal. So, that's fine. I

go to the terminal, but then I can just

bring it back in the session. So, now I

have my cloud code terminal running

right here, and then I also still have

the ability to look at all of my

different files and folders over here.

So, it's really the best of both worlds.

So, who is this for? If you want to

spend your day in a code editor and you

want cloud code right there next to your

code, this is the way to go. It's really

not that overwhelming. So, if you're

currently deciding if you should switch

from the desktop app to VS Code, I would

probably go ahead and do that. And last

but not least, we have number five,

which is VPS. So, this means that you

can actually run Cloud Code on some sort

of virtual private server rather than on

your local machine. So, similar to the

cloud on the web, except for rather than

anthropics cloud, you pay for some sort

of cloud yourself. And the way that I

like to do that is with Hostinger. And

because it's running on a remote server,

it can always stay on. So, why would you

do this? The code and the services on

there have to live somewhere. So if

you're running Docker containers,

databases, and automations, Cloud can

sit right next to them at all times with

access. And we have persistence, meaning

you can start a task, you can close your

laptop, and cloud keeps working on the

server. So I actually have a VPS session

of Cloud Code set up. And I've connected

it to a Telegram bridge. So I can now

talk to my Cloud Code wherever I am from

my phone right here. And it can respond

to me. It can look through my files. It

can create files. It's basically cloud

code in your pocket. And what else is

cool is if you have it running on a

virtual private server, you can SSH into

that from your own terminal locally or

from VS Code locally or even the desktop

app. So you can pretty much get all the

power. So the pros here it is it's next

to your real infrastructure direct

access to all of that. It's always on

and you can work across any device. The

cons are that you kind of need some

basic server knowledge. Although what I

did is I set up a cloud code project to

help me spin up and maintain my VPS.

It's also a little bit more setup

friction than the others. And Claude

does have real power if it's on a server

and can see everything on the server. So

you obviously want to be careful with

permissions and things like that. So if

you go to the link in the description,

you can see that Hostinger has a plan to

specifically help you launch Cloud Code

VPS. You can get started for as little

as six bucks a month. So that's pretty

cool. When you come down and choose an

option, you basically just get to

compare these different options of RAM

or CPU cores or bandwidth. I would

probably just start with this one. And

you can always scale up or scale down as

needed. And if you have no idea what

you're doing here, then basically just

use the Kodi AI assistant and tell it

about what you're trying to run and it

will probably help you be able to make

the right choice. And then once you get

in there, you'll have a dashboard, which

I'll show you guys. And you can also use

that if you need to help scale down or

up. And once you go through the setup,

you will see that you can choose a

24-month, 12-month, or 1-month plan. If

you're on one of the annual plans, you

can use code Nate Herk, and you can get

10% off, which ends up saving you a ton

of money. You can also get daily auto

backups. You choose your location. And

right here, you can basically launch

this with an app. So right here they

have cloud code which makes it super

easy to set up and get going. And then

once you're in your dashboard, you can

see the CPU usage, the memory, the disk,

all of this kind of stuff. And once you

notice that this is getting a bit too

high, then you can just scale up your

plan with a click of a button. But

basically all you need to do from here

is SSH into your actual server and then

install Cloud the same way you would do

on a terminal or anywhere else. And then

you have Cloud Code running there. And

you can set up sessions that last

forever. And you don't even have to

actually SSH in. You could literally

just hit this button right here, which

brings up the actual server terminal. As

you can see, we have this really ugly

terminal looking thing right here. And

then you can go to this doc, which

basically shows you exactly what you

need to do in order to actually install

and log into cloud code. And then it

looks the exact same as you would have

used it anywhere else. So, who is this

for? If you're running servers,

deploying apps, or you want an always on

AI assistant working on your code 24/7,

then this is the setup. All right. Well,

that is going to do it for today. Now

that you guys have watched this

breakdown, hopefully you understand

exactly which way you want to use or

which ways you want to use Cloud Code

and now you're ready to actually start

diving in.

Okay, so what does Cloud Code actually

do? Well, the short answer is that it

can do basically anything, which is why

it has been blowing up and which is why

I'm having so much fun using it. But you

can build apps, you can build websites,

and you can build automations. You can

even build like games. You can enhance

your personal workflows. You can debug,

refactor, and test and write code. You

can create API integrations. You can

generate documentation, handle git

workflows, data analysis, and content

pipelines. You can pretty much do

anything even now that we have like

browser use. So you can literally give

Claude Code the access to open up a

browser tab and look at it, screenshot

it, screen record it, click on things,

fill out forms. It's just really cool.

And the one mindset shift that I really

want you guys to adopt is genuine

curiosity.

Because when you first get into Cloud

Code, obviously you'll be following this

program, so I'm going to have things

pretty structured, but it might just

feel like

this is a very like loose program. not

not my course but like cloud code and it

was built in a way that it's insanely

customizable insanely hackable so that

you have unlimited possibilities so when

I say be genuine cur genuinely curious I

just mean if you are confused about

something ask it if you are wondering if

something's possible ask it if you want

to understand how you build something

just ask it and you can ask follow-ups

and follow-ups and follow-ups you can

have it design exercises for you to

understand concepts it's going to be

your best friend because anything that

is technical, it will know better than

you. Whether that's an API or whether

that's a tool or whether that's um some

command line, you know, interface

function that it's running, just ask it.

So, what I really like to do is when I'm

in my cloud code and I'm talking to it,

you can see what it's thinking, right?

So, I literally just like to read what

it's thinking and I like to read the

lines of command that it runs. And the

more and more you read what it's doing,

the more you understand it. So in this

section, we're just going to get some

initial kind of like setup and concepts

talked about. So cost, prompting,

permission modes, cloud models, tokens,

context, windows, built-in tools, and

cloud.md. So let's dive in. So the first

thing is cost, right? You have to be on

a paid plan. Um, you can start off with

pro. It's 17 bucks a month build

annually, but I would definitely

recommend you just go for the max. If if

you want to start with pro, you'll

probably just hit your limits pretty

quick and then you'll get frustrated and

you'll either upgrade or you just have

to wait an hour or a couple hours.

And real quick, I wanted to talk about

the ROI because yes, 100 bucks a month

is an expensive subscription in the

grand scheme of things, right? Like you

have n bucks a month subscriptions, 29.

100 seems like a lot and even if you

push it to 200, but it's all relative.

Think about the fact that a software

engineer costs around 11,000 bucks a

month or an annual salary of maybe in

this range

and you can get the output of a software

engineer, a full-time software engineer

for 100 bucks a month. That is crazy.

And that's the way I want you to think

about this. Not a subscription. Think

about it as a software engineer on your

laptop.

It's a complete mindset shift, right?

Because they can do everything that a

developer does. Basically, Enthropic,

the company that built cloud code, uses

cloud code for everything. They built a

tool called cloud co-work and they built

that in like 10 days with a team of two

or three developers only using cloud

code. That would have taken months and

that would have taken a massive team of

developers. They're even right now using

AI to write and review all their code

because humans were missing things that

the AI is catching. So, it's just like

it's crazy crazy leverage. It's not

marginal ROI. It is truly

transformational ROI. [snorts]

So prompting prompting matters, right?

Because cloud code at under the hood is

an AI model that can talk to your tools,

that can do things, that has access to

your files. And so prompting is so

important because the quality of the

clearness of your prompt and the context

that you feed it is directly tied to the

quality of output it gives you. So a

vague prompt produces vague results.

Garbage in, garbage out. Think of Claude

as a brilliant contractor that you just

hired. They have tons of skills, but

they have never seen your project

before. So, the more precisely

precisely the more precisely that you

explain what you want, including your

context, your constraints, and your

expected outcomes, the far better the

result will be. And as you guys, you

know, it's all about the reps. As you

guys start to talk to Cloud Code more

and more, you'll realize just how good

it is. And one key thing there is using

voice to text. So, just to show you guys

what that means real quick, when I speak

in natural language with my voice, I can

speak way faster than I can type. And I

speak way more, I guess, naturally.

Like, when I speak, I feel like I

actually unlock more thoughts because

I'm not having to be restricted by my

fingers. I'm restricted by just oxygen,

I suppose. So, I use this tool, which um

there will be a link for in the

description. Just go ahead and check out

the voice to text tool down there or I

can go like this. You see this little

thing at the bottom of my screen. I hold

this and now I can basically just talk

and I can even hit the space bar. So now

my hands can be off and I can just be

talking. So I can be brain dumping and I

can be talking about whatever and

telling Cloud Go, "Hey, I want you to

build this." And then boom, all of a

sudden my words have just appeared. So

that has been a major major productivity

boost, major unlock for me. And if you

guys don't have that tool, I would a

thousand% recommend that you get that

tool and you use that tool. Okay, let's

keep on moving here. [snorts]

So, bad versus good prompt example. Bad

would be something like build me a

website for my dog walking business.

It's going to look generic. Good would

be create me a simple landing page for a

dog walking business called Happy Paws.

It should have a hero section with a

headline, a list of three services with

prices, and a contact form at the

bottom. Use a clean, modern style with a

blue and white color scheme. Now, the

cool thing about this is this still

honestly isn't a great prompt, but what

you can do is you can feed that prompt

right here into Cloud Code. You can

utilize plan mode, which you guys will

understand in just a bit, and you can

let Claude code ask you the difficult

questions that it needs. So, pretend

right now you you want to build a

website. You are talking to the world's

best website designer.

You give that person this prompt. That

person is going to come back to you with

tons of questions. Okay. Um, what's the

this? What's this? What's this? Tell me

more. And you can let them adopt that

role of asking you questions. So it

makes your job so easy. You can say

things like you should be 95% sure

before you move on or ask me any

questions to make sure you understand

me. And that will literally make sure

that cloud code doesn't start building

anything until it completely understands

your request. So permission modes, we've

got three kind of main ones that I'm

going to cover. We've got plan mode,

which means Cloud can help you plan. It

thinks, it can read things. It can do

web search, but it won't actually build.

We have accept edits, which means that

cloud can read things, write files, edit

files without asking. But it still has

to ask permission for bash commands,

which means kind of like actually taking

action. And we have bypass permissions

mode, which basically means you talk to

Claude, it can go do whatever it wants,

full autonomy.

Now, this is beneficial sometimes when

you have come to a plan that you like

and then you shoot it off in permission

mode, in bypass permission mode, because

you don't want it to babysit it. So

there's some value there.

Now, here's what they look like in cloud

code. You can see at the bottom I'm

switching between plan, bypass, ask

before edits, and you literally just

toggle that with a button. So this is

the GUI, and we can just toggle it. You

can notice that this kind of looks like

the way that, you know, maybe Claude in

the browser looks or chatbt in the

browser looks. So that's your different

modes. Super easy. Now we have models.

So the number that's attached to the

back, don't worry about that. Right?

Like right now we're on Opus 4.6, SA

4x6. But these are the model families in

Claude. So we have Claude Haiku, Claude

Sonnet, and Claude Opus.

They have different strengths. They have

different weaknesses, and they have

different costs. And it's important to

understand. So Haiku is the fastest. It

is the simplest, and it's the most

lightweight, lightweight, and it's also

the cheapest. So it makes sense, right?

Sonnet is kind of like the balanced

version. So, daily coding, it's very

balanced, it's fast, and it's mid-range.

And Opus is a heavy reasoning model. So,

it's probably going to take the longest,

and it's probably the smartest, but it's

also the most expensive. Now, I will be

very upfront with you guys. I use Opus

for everything. The only time I will

switch to Haiku is maybe if I have

certain sub agents or I have tons and

tons of tokens to process. But when

you're just starting out, just keep it

on default or just keep it on Opus just

to get a feel for it, right? So here are

the models in the same interface. You

can type /model and it lets you choose

between default set or opus, right? And

it's just as simple as literally you saw

at the beginning of this clip. All I did

was I typed /mod and it popped up with

this option to change my model. So very

easy.

Now what do the numbers mean? I'm not

going to spend too much time here, but

it's basically just like the version. So

cloud [clears throat] 3 was the

original. Cloud 3.5 had improvements.

Cloud 4 was introduced. Cloud 4.5 had,

you know, more improvements. Cloud 4.6

Six has more improvements. So the models

just increase the number, right? So use

the model slash command. A good

strategy. Use Sonic for 80% of work.

Switch to Opus for complex architecture

decisions or tricky bugs. Then switch

back. Kind of like best practice. But

like I just told you guys, I just like

to use Opus, right? So what is a token?

A token is a unit. And that is basically

how you know we read in words and

letters. AI reads in tokens. So it's not

exactly one word. You know, a token is

not exactly one word. It's roughly three

to four characters. And I say roughly

because sometimes you'll notice like

this punctuation mark like this comma is

one. This period is one. Um here we have

in and that's two. And that also

accounts for the spaces as you notice.

This is also one. So it's like it's not

also it's not completely consistent. But

roughly

one token is about 75% of a word. So,

this is important to understand because

tokens cost money.

And we have something with all of our AI

models called a context window. The

context window is Claude's working

memory. So, just imagine that Claude has

a notepad. And when you're talking to

it, it writes down everything that you

said and everything that it said back to

you in this notepad. And when the

notepad fills up, it's bad, right? Like,

it's going to start to um lose track of

what's going on. And it also might just

have to reset.

So things that go into this context

window are the system prompt, your

tools, your cloud.MD files, MCP servers,

all of your conversation history, all of

the files, everything that Claude said,

everything that you said. And the con

standard context window is about 200,000

tokens at least at the time of recording

this. The models are getting better

every day. So it's important to know

that and it's important to contextualize

that one huge huge principle of cloud

code once we get more advanced is

minimizing token usage and keeping you

know they call it context management. So

that will be covered later in the course

but for now don't worry too much about

that. Just be aware of that concept.

Okay.

So here's why it matters. It fills up

and as it fills up you consume more

tokens which means you're going to hit

your limits. You also have this dilemma

or this problem of being lost in the

middle. Meaning information at the start

of the conversation and at the end of

the conversation get prioritized because

stuff in the middle can tend to get lost

because there's just so much data,

right? And then of course you have your

cost. More tokens is more computational

cost and um hitting your limit faster

because your subscription is based on

tokens.

So here is what we also call context

rot. So as you have more tokens build up

in a session, we significantly see or we

see a significant drop in the quality

and accuracy of the LLM. So if your LLM

all of a sudden, if Cloud Code all of a

sudden starts making things up, then

maybe compact your token window or maybe

open up a new session because as you can

see as there's more tokens the quality

just kind of takes a steep drop off and

this is seen across all the models. This

is a handdrawn sketch, right? But this

is basically how it works across all the

models. Context rot is a real thing with

AI.

So, here are some helpful commands that

help you with some context stuff. So,

slashcontext, it shows you the current

token usage breakdown. Slash compact

compresses the conversation and saves

key information so you can keep going as

if you still have all that history

there. Slashcle just wipes everything

and starts fresh. And SLR goes back to

an earlier point in the conversation

after a code change. There is something

that Cloud Code does called autocompact,

which means that it'll automatically

compress your conversation once you hit

that limit. So, when you're first

getting started, don't stress too much

about context Windows. It'll

autocompact, but just something, like I

said, I wanted you to keep in mind. So,

here's an example. I'm typing in /clear,

and that clears the conversation as you

saw. And now I'm typing in /context, and

it's pulling up all of the different

things in this project that are eating

up token usage. So, here you can see,

oops, didn't mean to go forward. I meant

to pause. Here you can see that in this

session, I'm using model cloud is 4.6

and my tokens are at 225,000

or sorry 22,000 out of 200,000. So I've

already eaten up 11% of my context

window. If I was to then scroll down,

you can see that there are other things

in here that are eating tokens. So I

have um you know all of these system

prompts, these system tools, these MCP

tools. I have MCP servers that are

taking up some context and I've also got

like skills and agent files, right? So

the more things you have in your

project, the more tokens that are going

to be consumed.

Okay, so now I wanted to talk about

built-in tools in Cloud Code. Now, when

you're using Cloud Code, it'll basically

tell you which tool it's using, and you

don't have to memorize these at all.

They're very intuitive, right? Like

read, write, edit, bash, glob, they're

pretty much intuitive. Bash means you're

running a shell command in your

terminal. So, if you open up your

terminal and type something, that's

that's a bash. A glob is looking for

things. A GP is also searching for

things. An ls is listing files that

exist. Web fetch is getting content from

a URL. Web search is searching the web

for a URL. And this is just a quick

breakdown so you're familiar with tools.

Um, now like I said, I off the top of my

head wouldn't be able to tell you what

they all do. Well, maybe I would now

because I've just read them so many

times, but you don't need to memorize

these. The reason I bring this up is

because when you hop into Cloud Code and

you see these words, you're probably

going to think to yourself, "What in the

world is a glob? What is a GP?" So, I

just wanted to get you familiar with the

fact that this just means it's looking

through files or it's executing

commands.

So, here's an example, right? I said,

can you create me an image using my AIS

logo? Um, it's computing. So, it has

these little things that will pop up. It

executed a skill called generate image.

We can see it's thinking. We can see

it's searching. It's using the glob. We

can see that it found the logo. We can

see that once again it's computing or

it's finagling or whatever words. Here's

a bash command. And this bash command

was running a script to go generate

that, you know, AI generated image. So

that's just a quick preview on what it

actually looks like and why I wanted to

bring up those different built-in tools.

Okay, so claw.md.

This is something you're going to hear

so many times. If you've ever built an

AI agent before or a chatbot or

anything, you've given it a system

prompt. Cloud.md is just a system

prompt. That's all. The reason it's

called claude is because we're using

claude code and MD means markdown. So

I'll show you guys an example of what

markdown looks like in a sec. It's not

scary. It's not code. So this system

prompt gives claude code instructions

about the project. Every single time

before like when you send cloud code a

message, every single time before it

reads your message, it reads its claw.md

file first. So it's a system prompt.

Now, there's kind of three main layers

that you want to put in your cloud.MMD

because if you think about tokens and

you think about what I just said, if

your cloudmd file is huge, that means

every single time you ask it a question,

it reads that whole thing and consumes

tokens really fast. So, keeping your

cloud.MD file lean is important. So, we

want the what, which is your text stack,

your product structure, any key packages

or skills. We have the why, which is the

purpose of each component. And we have

the how, which is how you want Claude to

work. Now, the good thing is Claude is

really good at building CloudMD files,

right? So, here is an example of the

beginning of my cloud.MMD file for my

executive assistant. You are Nate Herk's

executive assistant. Your job is to help

him spend less time on operations,

people management, and admin so he can

focus on learning AI tools and making

YouTube videos. This is his number one

priority. Everything else supports it,

right? Very clear goal. Now I also give

it other information so it can read

context about me, about work, about my

team, about my priorities and then I

list my tools and then I list you know

other you know project management

frameworks or anything that it needs to

know anything that's really important.

[snorts]

Now we have a cool command called /init

which basically initializes your project

by scanning your codebase and creating a

cloud.MD file. So if you opened up a

project and you don't have a cloudmd

just run slashinit and it will make you

one. So that's a pretty cool command.

Okay, that is going to do it for now.

Hopefully I didn't bore you guys too

much. You're done with slides. Let's go

actually get our hands a little bit

dirty with cloud code and start building

your first agentic workflows. So, super

excited. I'll see you guys over there.

Aenic workflows are changing how we

build AI automations. But not only that,

they're also changing the entire

industry with more businesses [music]

investing in Aentic AI to improve their

workflows. So, if you're looking to

start building AI automations to make

your life easier or you want to make

money building these for businesses,

then this is [music] the best place to

start. I've been building AI automations

for a little over a year now and I've

already helped thousands of people build

their first AI automation. So I do know

how intimidating everything can look at

first. So that's why in this video I'll

be telling you everything you need to

know and then I'm going to show you how

to build your first agentic workflow

from absolutely zero. My job is to make

this as easy to understand as possible

for you. So let's get into it. All

right. So before we actually build

anything, let's make sure that we're on

the same page about what aentic

workflows actually are. If you've been

building traditional automations, you

know the drill. You use a tool like make

or n. You drag a node onto the canvas.

You configure it. You connect it to the

next one. You make sure the right

variables are passing through. You test

it. You add another node. And you keep

going. And when you hit an error, which

you will, you read the error message.

You figure out what went wrong. You fix

it. You test again. And you repeat until

it works. You're basically building the

whole thing manually. And if it breaks

again later, you're the one who has to

go back in there and fix it yourself.

Now, this was a huge leap in the AI

automation space because it

significantly lowered the barrier to

entry and it allowed anyone from any

background to learn these tools and

build some really powerful automations

in a matter of days. But agentic

workflows completely flip that whole

process because instead of telling the

system how to do something step by step,

you're just telling it what you want and

then the agent figures out the rest. So

think about it like hiring a really

talented developer. You don't sit there

explaining the code or walking them

through the logic line by line. You walk

in and you explain the problem. You

describe the outcome you want and then

you ask, okay, what else do you need

from me? So that's what makes it aic.

The system reasons, it adapts, it asks

clarifying questions when it needs to.

It makes decisions. It fixes itself when

something breaks. And it does research

all to make your job as easy as

possible. Now I do believe that

traditional automation with a tool like

Naden isn't going anywhere. It's still

perfect for repetitive predictable

tasks. And there are two terms that we

use in the AI automation space.

Deterministic and non-deterministic.

Deterministic means predictable. And in

automation, predictable is beautiful.

Boring is beautiful because you know

exactly what's going to happen every

single time the automation runs.

Non-deterministic means that given an

input and you don't know exactly what

the output will be. There's variability,

there's judgment, there's AI, and AI is

non-deterministic. So our job as AI

automation builders is to make a

non-deterministic process as

deterministic as possible because

typically business processes are pretty

deterministic or at least as

deterministic as they can be. So that's

exactly where agentic workflows shine.

They unlock tasks that are too variable

for traditional automation stuff that

needs judgment calls at every step just

to be a little bit more dynamic. Maybe

research, maybe content creation,

customer support, lead genen. These are

messy processes that can involve a lot

of moving pieces. So with aentic

workflows, we can handle that

variability and the system actually gets

better over time instead of just setting

it and forgetting it or having to go

manually in and make improvements by

yourself. There's a reason why so many

builders right now are shifting to tools

that are a little bit more genetic like

cloud code or anti-gravity because they

fix a lot of the common struggles with

traditional automation. There's no more

finding and fixing errors manually. No

more setting up API calls yourself. No

more manually connecting to MCP servers.

No more getting stuck on the logic. So

here's a really simple way to think

about that evolution. Let's say you

wanted to get to a carnival across town

and you know roughly where it is, but

you still need directions. Traditional

automation is like using a paper map and

a compass and you're looking at the

street names and you're trying to figure

out your own routes. You're choosing the

streets to walk down and you can get

there and you will get there. It just

takes a little bit more effort and if

you make the wrong turn, you'd have to

figure that out and course correct. But

with Aentic Workflows, that's just like

pulling out your phone, googling for the

carnival, and then it basically gives

you this blue line and all you have to

do is follow it. And if you go off the

path, it will like recalculate and it

will make sure that you go back to the

actual outcome that you're looking for.

So in both scenarios, you can get to the

same destination, but it's just a

completely different experience getting

there. So let's talk about what's

actually happening under the hood and

what you need to know in order to build

an agentic workflow. So we're using a

framework called WAT. You could just hop

into Cloud Code right now and start

talking to the agent and honestly it

would do just fine. But without

structure, things get messy fast. Think

about it like a school locker. If you

just threw every piece of paper, every

homework assignment, every note from

every subject into a locker with no

organization, you could get straight

A's, but it would be tough because you'd

be digging through piles of paper. you'd

probably forget things or lose things

and that's why you would have finders,

shelves, folders, notebooks. Structure

makes everything easier. So, it's the

exact same thing here. We need to tell

cloud code how to stay organized and

that's why we do that using our

framework called WAT. W stands for

workflows, A stands for agent and T

stands for tools. Each piece of that

framework has its own job. So, let me

break that down. All right. So, first we

have the workflows which are the

instructions. These are instruction

files that are written in markdown,

which is basically just natural

language, but it uses things like pound

signs and asterisks so that the agent

knows what are the headers, what are the

subheaders, what's bold, what's

important, stuff like that. So, I'll put

a quick example right up here on the

screen if you've never heard of

Markdown, but just know it's super

simple and you could go read that and

you would not be confused at all. So,

think of a workflow like a job

description or an SOP, just a process.

It tells the agent what to do. For

example, we might have a workflow called

competitor analysis. The workflow tells

the agent to research businesses, then

gather data from five competitor

sources, then analyze those findings,

and then analyze our business, and then

create a PDF report. So, it's just

basically a process, a sequence of

steps. They're guidelines. The agent

then uses these guidelines to figure out

how to achieve that end goal. And here's

the cool part. As the agent works and it

gives you outputs, you can say, I liked

this, but I didn't like that, or go

ahead and change this, and it'll

actually update its workflow file so

that next time it calls on the workflow,

it will do better. Now, the A stands for

agent, which is the coordinator. This is

the actual AI. This is claude code

itself. This is the brain. It reads your

workflows and it reads those

instructions and it looks at what tools

it has available. And then it makes

decisions about which tool to use and

when. And if something breaks, it will

handle the error. It will research it.

It will figure it out and it will adapt

for you. So really just think of this as

like a project manager. You hand them

the instructions and they will delegate

tasks to the right people. Except for

not people. It's more so they delegate

tasks to the right tools and workflows.

So you don't have to figure out the

sequencing or the logic. Cloud code does

it. And then the T are the tools which

are kind of the workers or the actions.

Tools are Python scripts that actually

do the work. And this is where the ugly

code lives. But don't worry, you don't

have to touch it. Each tool will have

one specific job. The workflow is a big

process. A tool is just one specific

action like scraping a website or

generating a PDF. The agent then calls

these tools when it needs to based on

what it says in the workflow

instructions. So for research workflow,

your tools might be one to scrape a

website, one to analyze findings, and

one to generate a PDF. And here's the

best part. These tools also get

automatically built by cloud code, and

if they fail, they get automatically

updated and fixed by cloud code. They're

super modular, so you can call a tool

with a different workflow if you want to

later. So, how do these three layers

work together? Let me just show you how

this connects. Let's say that we give an

agent a task like research company X's

pricing and then create a PDF report for

me. The agent reads the workflow, the

instructions, looks at the available

tools and decides the sequence. So,

first it would call something like a web

search tool to find the relevant info.

Then it would call something like a

scrape website tool to pull content from

those URLs. Then it calls the analyze

finding tool to synthesize everything.

And finally, it could call the generate

PDF tool to create that branded report.

Now, the whole time it's reasoning and

it's making decisions based on what you

told it to do in the workflow and you're

not mapping it out step by step. The

agent handles the logic and updates it.

All right, so that's what I wanted you

guys to understand about Agentic

Workflows. All right, but before we

continue, if you want to follow along

with the video, you can download this

resource I'll be using in my community.

Once you're there, you just need to look

for the post with this video and you'll

find it attached as a markdown file.

Now, let's get back to building your

first agentic workflow. Okay, so we got

all of that stuff out of the way. The

first thing I need you to do is go to

Google or a browser and type in VS Code

or Visual Studio Code and go ahead and

download this. This is where we're going

to be using Cloud Code. So once you

install that, it's going to look like

this when you open it up. It's just kind

of like a welcome onboarding screen.

What I'm going to do is just break

everything down as far as what you

actually need to click on, what you need

to know because there's a lot of buttons

in here and it's probably a new

interface which makes it overwhelming,

but it's going to be simple. You'll see.

So before we do anything else, we have

to actually install the Claude Code

extension. You can see up here I've got

this little button where if I click on

it, it opens up Claude Code and we get

the little crab and we can now talk to

Claude Code. So, you're not going to

have that by default. The way you get

that is you go over to the lefth hand

side to the menu bar and you're going to

click on extensions. You are then going

to search for claude code. So, if you

just type in claude, it should pop up

over here and you'll click on it and

then you just have to install this

extension. Now, once you install this,

it will prompt you to sign in with your

anthropic or your claude subscription.

And so, you do have to be on a paid

cloud subscription in order to use cloud

code. You can see here on the free

version you don't have it but pro or max

or the higher max you will have cloud

code with opus 4.5. So once you're on a

pro or max plan then you will come back

into VS Code. You'll sign in with that

and you should be all set to start using

cloud code right here. So we've got that

configured. Now what I want you to do is

click on the button up in the top right

and close out of this window and you

should be able to see that you have

cloud code right here. So now in order

to really use cloud code we have to be

in some sort of project. So, if I go

over to the lefth hand side and I go all

the way up to the explorer, you can see

that it says no folder open, which means

basically we're not in a project. So,

you're going to go ahead and click on

open folder and you can see what I did

is I created a folder right here called

first agentic workflow and it's

completely blank. So, open up a blank

folder or go create a new one and then

select it. So, this is what your screen

should now look like. You've got your

folder on the lefth hand side with no

files in there. You've got these other

panels on the right and what we're going

to do is close out of the VS Code agent

and then we're going to open up Cloud

Code and then we're just going to get

rid of the welcome VS Code screen. So

what we have here is files on the lefth

hand side and this is where we're going

to see any folders that we create, any

of the files that Claude actually makes

for us. And then right here is where we

can actually talk to Claude code and

just think of this as your typical chat

GBT interface, your Gemini interface or

of course your Claude interface. This is

where the agent lives and then this is

where the files live. So this is where

we'll see the workflows and tools as we

mentioned. So you remember earlier I

talked about how we had to make sure

that our agent understands our structure

just like it wouldn't want to throw

notes and random stuff in a locker. We

have to give it structure. So, what

we're going to do is we're going to give

it this file that's called a claw.md

file. And if you want to get this, I

will have it available for download in

my free school community. So, this is

basically the onboarding document. We're

catching the agent up to speed as far as

how do we want to work. So, you can see

what we're doing is we're explaining

you're working inside the WAT

frameworks, agents, tools. So, then we

go ahead and explain. Layer 1 is the

instructions. Layer two is you. Layer

three are the tools. I'm not going to

read out this whole markdown file line

by line. You guys can access it like I

said, but I'll hit on a few of the

important things. So, we go over how to

operate. So we tell it first look in

your existing tools. Then you learn and

adapt when things fail. So when you hit

an error you read it, you fix the script

and you reset. So for example, if you

get rate limited on an API, you would

dig into the docs. You would see if you

could discover a batch endpoint. You

would refactor the tool to use it,

verify it works, and then update the

workflow so that error never happens

again. And then of course, you want to

keep the workflows current. We explain

the self-improvement loop. We explain

the file structure, which is going to

look like this. These are the different

folders we're going to have. We'll have

one for temporary files. We'll have one

for tools. We'll have one for workflows.

And then we'll of course have some other

different files in here as well. So

anyways, that is our cloud.MD file. So

what I'm going to do is I'm going to

drag it over here into the lefth hand

side because this is where we have our

project files and folders. So I drop it

in there. You can see it opens up over

here. We could also read it right there,

but I'm just going to go ahead and close

out of that. And now we have claw.md set

up right here. So what you can do now

that we have cla.md is you could do a

slash command, which is /init. And that

basically just initializes the

environment. But we could also just do

this in natural language. So, I'm going

to go ahead and say, "Hey, Claude, I

just dropped in a claw.md file that

explains how I want you to work in this

project. Go ahead and initialize the

project and get everything set up and

ask me any questions if you have any."

So, when I shoot that off, what you're

going to notice is that we can see

everything that Claude's doing. We're

going to see its thinking. We're going

to see its thoughts. We're going to see

what it's doing. So, in this case, it

literally says, "Okay, I'll read the

claw.md file to understand your project

requirements, and then I'm going to get

everything set up." And then, what's

cool is we can actually see what it's

doing. So, we can see that it read the

file. We can see now that it

understands, and now it's going to

create a to-do list and start to make us

those folders. So, temporary tools,

workflows, and you can see on the lefth

hand side, it actually just built those.

Now, one thing you may have noticed

right here is that when we're talking to

Claude, yours might look a little bit

different because you may be looking for

this bypass permissions mode. When we

talk to Claude code, we can either use

bypass permissions, we can use ask

before edits, we can use edit

automatically, or we can use just plan

mode. So, if you want to be able to get

bypass permissions mode, you have to go

to your settings, and then you're going

to type in cloud code, and then you just

have to allow dangerously bypassed

permissions. Now, yes, I know it sounds

dangerous because the word dangerous is

explicitly in there, but it's not too

bad. It's really just more so if you

give it a huge task and you don't do any

planning and you don't know what it

could do, it's just going to go execute

everything without asking. So typically

the flow that we like to follow is use

plan mode, have it build out a really

nice plan, ask you questions, and then

once you're confident in it, say, "Yep,

go ahead." And you turn on bypass

permissions, which you guys will see me

do that exact thing when we start

building this workflow. So it did ask

some questions. Do you want me to

continue with the straightforward

initialization? Do you want any Python

packages? Do you want to do a git

repository? Are there any specific tools

or workflows? Right now, we're not going

to worry about that. All I wanted to do

was just get this folder structure set

up. As you can see, we've got workflows,

nothing in there. We've got tools with

nothing in there. And we've got a

temporary folder with nothing in there.

So, I'm just going to go ahead and do

/clear, which is just going to reset our

conversation. All right. So, let's talk

about the actual workflow that we want

to build today. What I want to build is

a competitor research workflow. And I

want the deliverable to be branded PDFs,

meaning I want to give Cloud Code my

logo, my brand guidelines, and

information about my business. And then

it has to go research competitors. It's

going to create, you know, like maybe a

SWAT analysis or opportunities for us or

tracking what they're doing really well.

and then it's going to report all back

with a PDF that once again is branded.

So that's basically what I'm going to

start with because I know what I want,

but I don't know maybe the tools we're

going to use or the exact structure. So

I'm going to switch over here to plan

mode and I'm just going to say exactly

that. Hey Clude, so I've got an idea for

a workflow that I want you to build. I

basically at the end of it want a PDF

and I want it to be branded. So I want

to be able to give you my company logo

and my company brand guidelines and the

whole PDF output should have my logo on

there and have our colors and our

typography and stuff like that. But what

I want you to do is it's basically a

competitor analysis and research

workflow. So I want to also give you

information about my business that you

need to save. And based on that

information, you need to go find

competitors and you need to find me

areas to improve my business. Maybe see

what's working well for them and just

build me out a good way for me to keep

tabs on the market and what's going on

with my competitors. Yeah, that's kind

of what I'm looking for. So help me

build a plan for this workflow. And once

again, of course, you can ask me any

questions that you have if you're

confused. All right, so that was my

request. You can see it was all natural

language. It's very simple. It's

probably the way I would just speak to

like a human. And what it's going to do

now that it's on plan mode is it's going

to think. It's going to look at some

stuff. It might even do some initial

research in order to help build a plan.

And then what it's going to do is it is

going to actually ask us questions. Now,

I know that this might seem a little

intimidating, but really when I was

learning Claude Code, the way that I did

it was I would ask it a question and

then I would just read every single line

of what it's doing. If any of these

tasks or glob pattern like what is that?

If anything confused me, I would just

say what is this? What did you do here?

Why did you do that? So, it's really

about if you're genuinely curious and

you just read and pay attention, you

will pick this up really, really fast.

So, you can see it first of all explored

existing workflows and tools and then

it's looking at branding and PDF

capabilities. This was basically just

seeing if it could find any tools in the

folder for Python. It's reading other

files in our environment to see what's

going on. And now you can see that we

are in the question phase. So, it's got

four questions to start. First one is

discovery. How should competitors be

identified for analysis? I can either

provide a list. It can autodiscocover

based on my business info or hybrid. You

know what? So, let's just go ahead and

try autodiscocover based on my business

info. Then it asks us what business

information should the workflow collect

and save about your company. Company

description and value prop, product,

service, and pricing, target market, and

customer segments, key features. Let's

just do all of that. We wanted to get as

much information about us as possible.

For analysis, it asks what aspects of

competitors should be analyzed. We've

got products, services, features,

pricing and business model, marketing,

messaging. I want to analyze all of

this. Why would we not? So, I'm going to

choose all of it. For branding, it says,

"Can I use the existing branding assets

I found in your YouTube analysis

project?" And this is basically because

I've got a big project that this first

agentic workflow project sits in and it

can search through those as well. But

I'm going to assume that this is like

you guys setting up a first workflow. So

I'm going to say no, which is I will

provide different branding. So I'm going

to go ahead and submit those answers.

It's going to take those adjust the plan

a little bit and it may come back with

more questions. It may not. So we'll

see. And this is pretty cool because it

said I have all the information I need.

Let me launch a plan agent to actually

design the implementation approach. It's

asking us how often do we want to run

this. I'm just going to go with monthly

for now. For the output, it asks if we

want anything else besides a PDF. That's

pretty cool. But I'm just going to go

PDF. And then for the budget, what's

your comfort level with API cost for

this workflow? I like how it's showing

us different approaches here. And I'm

just going to continue to go with the

recommended approach. And we're going to

go ahead and do this middle one. All

right. So, at this point, it actually

finished the plan. So, if I scroll all

the way back up to when it started

telling us, you can see this is super

comprehensive. So, I'm still scrolling.

Okay. Competitor analysis workflow

implementation plan. Build a monthly

recurring competitor analysis system

that automatically discovers

competitors, researches their offerings,

generates a fully branded PDF report

with actionable insights. So user

requirements would be discovery,

business info, analysis, output,

frequency, budget. We've got the

architecture. We've got the text stack.

So it's going to be using cloud sonnet.

It's going to use firecraw and

perplexity. It's going to use sonnet.

And it's going to use report lab for pdf

generation. So it'll probably prompt us

to go grab an API key there. And it's

also going to generate charts using

mattplot liib, which I believe is a

python extension or plugin. And it's

going to help with charts. It's also

going to add some things in our folders

over here. So you can see it's going to

add a new folder called brand assets,

and that's where we will upload our logo

and our brand guidelines. And it's

basically planning to create a few

different things. It's going to create

some files in the temporary folder. As

you can see, it's going to create a

workflow called competitor analysis. And

it's going to create these five tools.

So, collect business info, discover

competitors, research competitors,

analyze competitors, and generate

competitor PDF. So, exactly like I said,

it's going to create this workflow. It's

going to create these tools, and then we

should be good to run it. Now, one thing

I noticed is it has a brand

configuration file, and this basically

made up our brand information, and it

would probably want us to come in here

and choose, you know, a name and maybe a

logo path. But what we're going to do is

we want to actually just drop in those

files for it. So that's something that

we will have to change, but we'll just

keep going for now. We can see that it

decided how to handle edge cases like

competitor websites block scraping or

insufficient competitors found, rate

limiting, invalid brand assets, and data

completeness issues. It's also giving us

a cost breakdown, which is pretty cool.

So the first run will be about a dollar

and a half. It's also going to be doing

subsequent runs on a 30-day cycle, which

will be a huge cost savings because it's

going to cache some of the data. And

then if you're adding some new

competitors, it'll be maybe another 50.

So anyways, that is the end of the plan.

We could basically go ahead now and auto

accept or we could keep planning. And I

do want to say no keep planning because

there's one thing I want to change,

which was our brand assets. So what I'm

going to do is I'm going to take a logo,

drag it into the lefth hand side. Take

the brand guidelines and drag that into

the lefth hand side. And you can see

that we have these things up here that

pop in and we can actually see them.

That plan looks good. The only change I

want to make is about the brand

guidelines and the assets. So I just

dropped you in two files, AISpng.png

and AIS brand guidelines.png.

Those are the ones that I want you to

use to create the branded PDF. So look

at those, extract the information out of

them and make sure that the logo and the

colors and everything appear on the

final output PDF. And if you need to,

you can throw those into a folder in

this project to keep things organized.

So this is awesome. It said, "I found

your logos and I'm creating a brand

asset guide." So we've got the logo and

then it also extracted our colors and

typography and now it's going to update

the plan to use those assets. And now

since that has been changed, we're going

to go ahead and auto accept the plan.

Hopefully it will get working for us. Of

course, it's going to create a to-do

list and then it's just going to start

building all these different scripts,

whether that's a workflow or a tool. And

then it's going to test the workflow.

And like I said, it'll probably have to

come back and ask us for an API key or

something like that. All right, so the

workflow is ready. We can see that we

have our branded assets set up. We've

got the workflow completed. We've got

the Python tools completed. We've got

some setup files. So, we also have a

readme that we could open up, which

should basically just tell us pretty

much how this actual workflow works. So,

that's pretty cool. Now, we do have to

go get two API keys to start. We need an

entropic key and we need a firecrawl

key. So it does actually tell us that

here again we have to install

dependencies. We have to set up those

API keys and then we have to run the

workflow. So first of all to install the

dependencies I'm just going to say can

you do this and then paste in exactly

what it gave me. And so it's interesting

it asks us to do that when it could have

just done it itself. As you can see it's

able to just run that command for us. So

once it did that now it says okay you

have to go create two API keys. So we

need to create av file which is just

going to be a copy fromv.ample.

So I'm actually just going to run this

command and it's going to copy that file

for us. And now we have an actualv file

right here. And so you can see it says,

"Okay, cool. Now we need your enthropic

key, your firecall key." And if I open

up the it gives us those placeholders.

So basically all we have to do is go

grab those keys and then put them in

here instead of these placeholders that

you can see right there. So first let's

go to Enthropic. I'm going to go to my

cloud developer platform. I'm going to

create a new key. This one's going to be

called competitor analysis demo. We're

going to have this key right here. Copy

that and go into VS Code. Paste it in

there. And then the next one we need to

get is the firewall key. So, you can use

the link in the description to go to

Firecrawl. You can actually get 10% off

and 1,000 free credits if you use code

Nate and use the link in the

description. But I'm going to go to my

dashboard here. And then all I have to

do is grab my API key from right here,

paste it into this section. And then

what you have to do is make sure you

save this file. So you could do crl S or

you could just go file, save. But now

that that file has been saved, we

actually should be good to go ahead and

run the workflow to see if it works. So

before I do that, you can see that we

have this little thing down here, which

is context. So 23% of your context

remaining until autoco compact. So,

usually when this goes over 60%, I

usually just like to clear because

there's this thing called context rot,

which basically means the more and more

you use one conversation, the worse the

model kind of gets. So, we're going to

clear the conversation. We're going to

go ahead and ask it to run competitor

analysis and then we're going to go

ahead and see what happens. Now, the one

thing I did notice is that we still

haven't given it a ton of information

about our business. So, I am a little

confused why it hasn't asked about that,

but we will see what happens. I'm going

to keep it on bypass permissions mode to

just see what it does. And I'm going to

ask it to generate a competitive

analysis. and I'm going to give it a

really small amount of information about

our business. Hey Claude, I need you to

help me run a competitor analysis. My

business is called Get Leads with AI and

we basically help you scrape leads,

build lead lists, and do personalized

outreach at scale using AI. And we're

starting to see a lot of competitors pop

up. So, I want to understand our

opportunities and what we need to be

doing better. All right. So, what

happened there is I just shot off a

prompt and I didn't explicitly say like,

"Hey, go use your competitor analysis

workflow." But what it's going to do is

it's going to think about what we have.

So you can see that it just searched

through our workflows. It searched

through our tools. It said we already

have a competitor analysis workflow set

up. Let me read how this works and let

me just go do it. So let's just see what

it comes up with. I'll let you guys know

if we have any questions. Otherwise,

I'll check in with you guys when we get

that output. Okay. So here we are

getting some questions. So this is the

part where it realized it didn't

actually have enough information about

us yet. So what's your primary target

for get leads with AI? We're just going

to go with um we'll just say marketing

agencies. For pricing, I'm going to go

with credit based usage. What's your key

differentiator? I'm actually going to go

ahead and say other and I'm just going

to say our key differentiator is an

all-in-one platform. But make sure

you're saving all of this information

that I'm telling you about my business

somewhere in this project so I don't

have to tell you it again. And so I'm

pretty sure it would have done that

either way because that's kind of the

whole point here. But just to make sure

that it does it for the sake of the

example, I wanted to show you guys you

have the ability to just tell it to do

things. So got it. I'll save the

information. So that's all you have to

do. And now it's going to continue on

with its to-do list. And actually it

does come up with some more questions.

So we're a single all-in-one product and

our price range, let's just say 200 to

500 a month. Now this is good. I know

what you guys may be thinking is that's

a lot of questions. Well, the thing is

as you use it more and more, it gets

smarter and smarter because each time

you use it, you know, it has more

information and you you give it

feedback. So, yes, the initial setup may

seem like a lot, but think about the

questions it's asking and think about

how good it's going to get now that it

has all this info. So, you can see what

it did is it created this file right

here called business profile JSON. And

this is where it decided to store all of

the information about our business. And

now, if we ever tell it something else

and it needs to add like a new memory or

fact about us, it will just go ahead and

update this JSON file. Here's a great

example of it fixing itself. So, it

basically went ahead and started looking

up for competitors and it found an

error. So, I see there's a uni-ode

encoding issue with the script on

Windows. Let me fix that. It reads how

to fix it and then it goes ahead and

fixes it because there were some emoji

characters or something like that. And

then it said, "Let me update it." And

what it's doing now is it's actually

changing the script and changing the

tool to make sure that that error

doesn't happen again. It's also now

created a new file called competitor

list. So, it was able to do research and

find different competitors like Apollo,

Outreach, Clay, Instantly, Lemlist. And

now if it ever needs to save more

information about different competitors,

it will just put it here. All right,

looks like it's finishing up right now.

So it found some key insights. You're

positioned as a mid-market blah blah

blah. Your eight main competitors, what

you're doing right, critical gaps you

need to address, top three

recommendations. Let's see what those

are. Add white labeling, introduced $99

to $149 starter tier, and double down on

build for agency's positioning. So it

created three different files or sorry,

four different files. It created the

business profile, which we looked at. It

created the analysis, competitor data,

and the PDF report. Wow. So it created a

new folder called competitors and it

made an individual file for every single

one of our competitors. So that's really

cool. We can actually see a lot of data

about them now. It created a folder

called analysis history. So this is

where we can see pretty much all of the

data that it ran and got for this

specific run. And now of course it has

the PDF. So let's check out the final

output. All right. So here it is. Now I

can definitely say that these are my

colors and the typography. So that's

good. But I don't see the logo. And I

really I think it's just because it is a

white PNG logo. So I bet that it's up

here. I just think that we probably

can't see it. But anyways, we'll see if

we can fix that. For now, we've got

executive summary. We've got business

profile. We've got competitive landscape

with feature analysis. We've got

competitor profiles, so high threat,

medium threats. We've got all these

different companies with strengths and

our advantages. And then we also have

our strategic recommendations at the end

that we saw earlier. So, really the

problem with this report is that our

logo isn't visible because it's white.

You can also see that it said that that

run costed $143. So, not too bad. But

what I'm saying now is that's great, but

we can't see the charts or logos. I'm

assuming because they're the same color

as the background. Investigate and fix

these issues. Now, typically I would put

this in plan mode and go back and forth

a little bit again, but for the sake of

the demo, I want to see how good it's

able to do when we just let it run with

a super super vague request, as you can

see. All right, so here's the thing. It

said the PDF generator has several

problems and listed those out. And now

it's going to go ahead and fix those

issues. So once again, this is just me

telling you guys about you have to run

the workflow a few times to discover

those holes. And once you discover those

holes, it'll fix them. And then you'll

get to a place where you have more of a

battle tested workflow. Okay, so it

regenerated the PDF. And once again, we

talked earlier about the caching. It's

saving all the data it had already. So,

it doesn't have to do a new search,

which is really good. And in the future,

it will still do current research, but

it already has the business profile

about all of our competitors, and it's

already researched them. So, now it just

has to see if there's anything new. But

anyways, let's open up the new report

and see how it looks. All right, so

here's the new report. Okay, so we've

got competitive intelligence report, get

leads with AI, today's date, and now we

do see the logo. So, executive summary,

we can see this business profile once

again, competitive landscape, competitor

profiles. However, there we go. But we

can finally see a pricing analysis chart

which looks pretty solid. Cool. So, at

this point, it would just be a matter of

making tweaks cuz obviously this isn't

perfect. There's some things we might

want. We might want more details cuz

like up here, you know, it's pretty it's

not super super wordy and super

detailed. So, maybe you like that, maybe

you don't. At this point, you've got

enough info and you've got every tool

you kind of need. And you just go back

and forth and ask for feature

enhancements. And once again, you can do

that all with completely natural

language. But you can see I didn't have

to go look at any API documentation. I

didn't have to figure out how to prompt

something to run a competitive analysis.

I didn't have to go figure out how to

generate these PDF reports or charts. It

handled all of that for me. So, I hope

you guys were able to follow along and I

hope you're excited to go build your

first agentic workflow. So, as you can

see, building your first agentic

workflow is actually so simple. But if

you still have doubts about what you

need to do or where to start, you can

always join my community. In here, you

can get every single resource that I've

ever used in my YouTube videos. All the

templates, the workflows, the prompts,

the files, all completely free. Also, if

you ever have a problem making something

work, you've got tutorials in there on

different topics, and the support of

over a quarter million people willing to

help you. The link for this is down in

the description.

All right. So, even if you don't know

how to code or if you've never touched

an IDE before, you're going to be just

fine. IDE stands for integrated

development environment, and you don't

even need to know that it's said for

that. So, what we're going to do is

we're going to get into cloud code and

I'm going to walk through everything

that you need to know because it can be

a little intimidating, but I'm going to

show you exactly what you need to look

at and what you don't need to look at.

And by the end, it's going to be so much

easier than you probably thought. So,

the first step is you need to go to

Google, search for Visual Studio Code,

and then just download this. It's

completely free to download. And this is

where we're going to be using Claude

Code. Once you open that up, this is

what it's going to look like. And the

first thing that I want you to do is go

over to the lefth hand side and click on

extensions. And once you get in here,

just search for Claude Code. And then

when you click on that, it's going to

allow you to install the Claude Code

extension for VS Code. And that's how we

actually use it. So if you don't have a

Claude plan, you are going to have to go

get on a paid plan for Claude. You can

start at 17 bucks a month. And this

actually allows you to get Claude Code.

As you can see, includes Claude Code

with Opus 4.5. So you do have to be on a

plan. And then once you open up the

extension in here, it will prompt you to

log in with that email that you have

that plan for. And then it will

basically sync it everything over here

and you'll be able to use it. So the

next step then is to open up a project.

So on the lefth hand side, instead of

clicking on extensions, you're going to

click on explorer. And this says you're

not in a project yet, you don't have a

folder open, you need to open one up. So

I've got a folder right in here called

Agentic Workflows Demo. And that's the

one that I'm going to open. If you don't

already have one made, just go ahead and

create one first and then you can open

that up. And so you'll see if I click

into this one, there's nothing in here.

It's a completely blank project. So, I'm

going to select that folder. And now we

have this right here. So, this is our

file explorer. This is where we can see

Aentic Workflows demo. And then on the

right hand side, what I'm going to do is

click on this button up here, which

looks like the Claude logo, and it says

cloud code open. So, I open that up. I'm

going to close out of this main window.

And now, what we have is cloud code,

which kind of looks like a chat GBT or a

regular claude interface where we can

talk with our coding assistant. So, this

is what your screen should look like.

Once you get here, let's talk about what

comes next. Okay, the environment that

we're currently working in, cloud code

within VS Code. On the lefth hand side,

we've got our files. So in ours right

now we have one called agentic workflows

demo but there's no other files in

there. This is where cloud code will

actually build workflows for us and

build files and things like that and

we'll see them populate on the lefth

hand side. Now on the right hand side

this is where we have our chat interface

with the agent itself. This is where we

do our planning. This is where it asks

us questions and this is where it

actually executes actions and once again

we'll be able to see all of that live.

So now I wanted to tell you guys about

the framework that we're actually using

today to build our agentic workflows.

It's called WAT which stands for

workflows agent and tools. So the agent

itself is cloud code. That's who we talk

with. That's what the AI brain uses to

build workflows and tools. The workflows

are going to come in a format called

markdown, which just looks like this.

It's natural language. It has headers

and it has bullet points and bold font

just to make it easier to read, but it's

literally just a natural language

document. And then the tools come in

Python. So this is the logo. It'll be a

py file, which I'll show you guys. And

this is the ugly stuff. This is where we

actually have code that I don't really

want to look at. You guys don't want to

look at, but luckily we don't have to.

So, what's the difference between these

workflows and tools? Well, workflows are

processes and tools are actions to take.

So, let's go back to our analogy of

like, you know, food and maybe making a

cake. So, when you want to make a cake,

you've got a recipe and then you've got

a bunch of ingredients and you have to

figure out what to do with them. So,

basically, the agent is a chef and the

chef needs to make a cake. The chef is

going to either read a pre-existing

workflow, which is a recipe to how to

make the cake, or the chef is going to

build its own recipe. And within the

recipe, it'll say, you know, like crack

two eggs into a bowl, add a cup of

flour, whatever. Those are the tools. So

eggs are tools, flour is a tool, sugar

is a tool. And so that's how the chef,

the agent uses a combination of recipes,

workflows, ingredients, tools in order

to make something, which is either a

cake or an agentic workflow automation.

So now that you guys understand that

framework, we need to make sure that cla

code understands that framework. So what

I'm going to do is I'm going to drag in

a file. And this file will be available

for download in my free school

community. The link for that is down in

the description. And this is our

claude.md file. So every time that you

set up a new project in cloud code, you

have to give it a cloud. and file. They

won't always be the same, but when

you're building agentic workflows and

you're using a WAT framework, you can

just use this and copy and paste it

every single time. This is basically

telling Cloud Code how to work. This is

its job instructions and description.

So, if you were to go get a job at a

grocery store on your first day, they

wouldn't just let you loose. They would

say, "Hey, we're going to get you

onboarded. Here's what you do. Here's

what you wear. You know, here is

specific tasks you do." So, here we're

telling the agent, you're working inside

the WAT framework, which stands for

workflows, agents, and tools. We have

three layers. The first one is

workflows, which are the instructions.

The second one is agents, which is you,

the decision-maker. And the third one is

tools, which are the executions. So we

talk about why this matters. The AI

tries to handle every step directly,

accuracy drops fast. So if each step is

90% accurate, then you're down to 59%

success after just five steps. So

basically, we're just explaining why

we're doing it like this. We then talk

about how to operate. So you look for

existing tools first. You learn and

adapt when things fail. You keep your

workflows current, blah blah blah. We've

got a self-improvement loop. And then

we've also got a file structure. So,

like I said, Claude Code when we're

working with it is going to create

files. It's going to create tools. It's

going to create maybe temporary docs to

look at notepads. And when it does this,

it adds them on the lefth hand side. So,

if we don't tell Claude how to organize

its files, it's going to get messy quick

to the point where I don't understand

where things are, and neither does

Claude code. So, we're just giving it a

nice structure for workflows, tools,

temporary files, things like that. And

so, obviously, you guys can read this

whole thing. I don't want to spend time

reading this line by line. But really

the moral of the story here is this

helps Cloud Code understand the

framework we want to use, how to build

workflows, so that when I'm talking to

it, we're on the same page. All right,

so what we want to do now is have Cloud

Code read that and then set up our

actual file structure. But before that,

I wanted to show you guys one thing at

the bottom when you're talking to Cloud

Code, which is the mode. So you can be

on ask before edits, you can be on edit

automatically, you can be on plan mode,

and you can be on bypass permissions. So

all of that just gives Cloud Code a

different level of autonomy. If you

don't want it to do anything and you

just want to make a plan, you start with

plan mode. And this is really important.

and I'll show you guys how this works.

If you wanted to ask for edits, you can

have it do that. If you want it to just

edit automatically, you can have it do

that. Or if you want to have it just

bypass permissions and just completely

go, then you choose that. Now, if you

don't see this option in yours, you have

to go to your settings, and then you'll

type in Claude code, and then you will

enable allow dangerously skip

permissions. And I only really like to

do this if I'm sitting next to Claude

watching it work. And if I realize it's

going off track, I can just kind of poke

it and steer it back in the right

direction. So, now that we've covered

that, I'm going to be on bypass

permissions mode, and I'm going to say,

"Hey, Claude, I just gave you a claw.md

file. I want you to go ahead and set up

this project so that we're ready to go.

We're ready to build a workflows

together. So, as I shoot that off, you

can see that this is very similar to

chatbt except for in here, we can see

everything that it's thinking and doing.

So, let's just start from the top. It

says, "Okay, cool. Let me read the

cloud.MD file to understand the project

setup requirements." And then we can see

it actually did this action. It read it

read this file that lives here. And now

it said, "Okay, cool. I understand the

WT framework. Let me check what already

exists in the project and then I'll set

up the required structure." As you can

see, it then goes to list the current

project contents. And there's nothing.

The product is empty except for the

claw.md file. Let me set up the right

structure. And so you can see it creates

a to-do list. It thinks, it searches, it

updates the to-dos, and it basically

goes through this step-by-step process

that you can have full visibility into

and see what it's doing, see how it's

thinking until we're done. So now it

looks like the to-dos are pretty much

all the way done. And it's going to come

back and say, "Nice, we're all set up.

What do you want me to do next?" And you

can actually see in real time on the

lefth hand side, we now have different

files. We've got our temporary folder,

we've got our tools folder, we've got

our workflows. Obviously, there's

nothing in these yet besides just some

read me and some basic stuff, but that's

why we gave it this folder structure so

that it keeps it organized and it

doesn't just throw a bunch of things in

a random order. Cool. So, it says ready

to build a workflow. Let me know what

you want to accomplish. Awesome. So,

we're all set up. Let's actually start

talking about the workflow that we want

to build. So, what I've got is this list

of remote jobs. So, I searched for

social media. There's 622 remote jobs.

And let's say I want to apply to all of

these. Well, that would be really tough

to log all of these manually. And

there's multiple pages. There's 21 pages

of these jobs. So, what we can do is we

can have Claude Code look at this stuff,

get all the jobs we need, and then put

it into an Excel sheet for us. And for

this, we're going to be using a tool

called Firecraw. Firecrawl lets us do

tons of different actions, and it lets

us basically take a website like

McDonald's right here. I can drop in the

URL, and I can ask for a scrape, and

it's going to go ahead and grab all of

the information from that website. So,

in this case, I just requested markdown,

and it just pulls back all of the text

from the website. As you can see, it is

a lot more powerful than that. It can

turn websites into LLM ready data.

Whether that's scraping the data,

getting screenshots, mapping the data,

crawling the data, searching,

extracting. There's a lot of different

things that we can do with firecrawl.

Now, the thing is we want to just say,

"Hey, cloud code, use firecrawl. Just go

after it. Use whatever the different

tools that firewall offers in order to

accomplish the job that I've got for

you." And so, we do this using a

framework called MCP, which stands for

model context protocol. Now, I know that

this may just sound like some tech

jargon or some gibberish. So, let's try

to contextualize this a little bit.

Think about Gmail, for example. In

Gmail, you've got an action to send an

email. You've got an action to draft an

email. You've got an action to get a

bunch of emails. There's so many

different tools within that tool. So,

MCP basically says, "Okay, cool. The

agent is going to figure out how to use

all the tools, when to use all of them,

what parameters to fill over, all that

kind of stuff so that you, the human,

don't have to think about that. So, if

we go back to our example of making a

cake, let's say we realize, okay, so for

this cake, we need eggs, flour, and

frosting." Okay, well, how do we do

that? Well, let's just give our agent

access to the supermarket MCP and say,

"Okay, whenever you need a new

ingredient, just go to the supermarket

MCP, grab what you need. I don't really

care. Just figure it out and then come

back with the right ingredients." Rather

than saying, "Okay, cool. So, like eggs,

let's go to the egg store. Flour, let's

go to the flower store. Frosting, let me

go to the candy store." We're just going

to get everything in one spot. And

that's the power of MCP. So, in

Firecalls Docs, you can see that they

have an MCP server, which is amazing.

And this lets us get stuff like web

scraping, crawling, searching, all this

kind of stuff that we want in any of the

tools that we want to use. So right

here, I can click on running on cloud

code. And this shows us how to add the

firewall MCP server using the Cloud Code

CLI. So what I'm going to do is go ahead

and copy this message right here. I'm

going to come into Cloud Code and I'm

going to clear out this conversation

history. And I'm going to say, "Hey

Claude, I want you to help me install

the Firecrawl MCP server. You need to

install it using this command in the

Cloud Code CLI." And then I paste in

that command. And what you'll notice

here is that it's prompting us for our

API key. And so an API key is basically

like a password. And I don't actually

want to give it to cloud code. I don't

want my API key to be stored in the

conversation history of cloud code. I

want to just put it into the file or

into the project locally myself just to

do it a bit more secure. So I'm going to

say go ahead and get this initialized,

but I'm not going to give you my API key

directly. I'm going to put it into the

EMV file. So help me get that set up as

well. So I shoot off that message. It's

going to think about how to actually

help me set all this up. So it's

checking in on the existing file. It's

checking in on our project configuration

and then it's going to help us actually

do this. Okay, so it said that I've

added the API key placeholder to yourv

file. Now you just need to add it there.

So thev file is on this lefth hand side.

I'm going to open that up and you can

see now it says cool firecall mcp server

put in your API key right here. So I'm

going to delete this. I'm going to go

into firecrawl and I'm going to go to my

dashboard. So if you haven't already

sign up for firecrawl, you can get

started for free and you can get 500

credits right away which is more than

enough to play around with. And then you

can see right here API key. So I'm going

to copy this. I'm going to paste it

right here into the actual MV file. And

then I'm going to go to file and save

this to make sure that it actually gets

saved on our project. And then you can

see it says then run the MCP add

command. And it gives me all this

reasons and I actually don't understand

what this means. So I'm just going to

ask it to see if it can do it itself. I

don't exactly understand how to do that.

I have added my firewall API key to thev

file. Would you be able to actually just

run this command to make sure we can

install the firewall MCP server? Okay,

so it went ahead and installed the MCP

server. Now, something I did want to

bring up is that when it actually runs

that command with this bash operation,

it does put in the API key right here,

which technically will be stored in

conversation history. So, in this case,

we're fine because this is a free key.

It doesn't have much access, and I'm

probably just going to rotate it right

after this video. So, what you would

want to do in an environment where you

have a key that has a lot of risk is you

would want to have Claude Code just walk

you through how you can run it in your

own terminal in order to make sure that

Claude never actually touches the key.

But still best practice always store

them in av way if you ever are pushing

something to a public repository

anywhere or someone gets access to your

files then that's all going to be

encrypted. So now we are pretty much set

up for actually starting to build this

agentic workflow. So I'm going to do a

/cle start a new conversation and what

we're going to do is like I said earlier

we're just going to explain in super

clear natural language what we want. So

I'm going to go ahead and switch this to

plan mode which I would always recommend

doing before you actually start building

an agentic workflow. I'm going to go

back into this tab and I'm going to grab

the URL from this page where we have 622

job opportunities here for social media.

Coming back into Cloud Code, I'm just

going to start talking to it. So, I'm

going to paste in this URL and I'm going

to say, "Hey Claude, I just gave you a

URL for a website that has a bunch of

job opportunities. There are about 622

job opportunities here, but they're

spread across different pages." So,

there's like 21 total pages. And what I

want you to do is go ahead and scrape

all those for me, and I just want you to

put those into an Excel sheet so that I

can actually look through them, you

know, do things with them. make sure

you're getting all of the relevant

fields that I may want. So, that's kind

of my overall plan. Let me know if you

can help me make that project

requirement more robust and you can feel

free to ask me any questions that you

may have for me to make sure that we can

build out this workflow in a really high

quality way. So, just shot that off in

plan mode. So, it's going to do a lot of

thinking. It's going to reason about

like the way that we should actually do

this. Hopefully, it understands that it

can use Firewall's MCP server. As you

can see, it's searching that right here.

And then what it's going to do is it's

going to come back to us with tons of

questions, I'm sure. And then it's also

going to come back to us with a plan. So

once I'm able to approve that plan, it

will start actually building the

workflows and the tools for us. All

right. So here we are with our first

round of questions. Do you want me to

also scrape each individual job detail

for more complete info like company

name, full description, benefits or just

the listing? So for the for right now,

we're just going to go with the actual

listing. For the output location, can we

So output location, it says where should

I save the Excel file? I'm just going to

go ahead and do a local in the temporary

folder which we've created right over

here. So I'll choose that. And then for

filtering, do you want any filters

applied or should I grab all 622 job

posts? Now, what I'm going to say here

is other and I'm going to go ahead and

grab all the jobs. But I'm doing this as

a demo for how to build an agentic

workflow. So just go ahead and grab only

200 for now just to prove that this

concept works. So I've submitted those

answers and now you can see it's going

to keep on going with its plan. So we

just got back this plan. I'm going to go

ahead and give this a quick review, but

also for the sake of the demo, I want to

see how well it did on the first shot.

So realistically, what I would do is I

would go ahead and read this whole

thing, and if there were any adjustments

to be made, I would go ahead and make

those. But what you can see is it gave

us a pretty comprehensive plan of what

it's going to do. It's going to create a

tool called scrape daily remote. It's

going to create a workflow called scrape

job listings, and then it's going to

actually execute that scrape and get us

all this information. So I'm going to go

ahead and say yes and auto accept. So it

just spun up that to-do list. It's going

to start going, and I'll check in with

you guys when that's done. All right,

that just finished up. We can see that

we got 209 done. We have different

metrics here. We have different

locations and also created a tool and a

workflow. So if I open up this folder,

we can see we now have a scrape daily

remote jobs tool. And in the workflows,

we now have a scrape job listings

workflow. So basically meaning next time

we ask it to scrape jobs, it's going to

be able to do it better and it has more

direction because it's already done it.

And if it has any mistakes, it will

update the workflows and the tools so

that the next time it's even better. But

let's go ahead and take a look at the

output. So it said that it stored it in

the temporary file. So right here, temp,

and we've got social media jobs Excel.

All right. So, this is the Excel sheet

that it created for me. I'm going to go

ahead and zoom out a little bit so we

can see, but it's got like different

filters on here already, which is pretty

cool that it did all this itself. We've

got job title, we've got job type,

position, location, experience,

category, salary, description, summary,

tags, we've got the actual URL, and

that's pretty much it. And like it said,

it was able to get us, I think it said

209. So, yep, this is 209 total job

postings just like that. So, we're going

to go ahead and try a different use case

now that uses the Firewall MCP. But what

I wanted to show you guys is down here

we have context. So it says 45% of your

context is remaining until it will

autoco compact. And so you guys have

might have heard of something called

context rot. It basically just means the

more context that you have in a

conversation history with an AI model,

the worse it kind of gets. So typically

whenever my context gets over 60, I'll

probably just compact it or reset and

then keep going. So what I'm going to do

is I'm just going to go ahead and click

this right now and it's going to compact

our workflow and all of our conversation

history so we can keep going, but it

still remembers the important things

that we've done. All right, so that's

been compacted. And so it basically just

summarized everything that we've done.

So let's try something else now. Let me

look at this same website, but now

there's no search filter. So there's

214,000 jobs. I'm just going to take the

URL and I'm going to go into cloud code

and say, "Hey Claude, I've got this URL

that I need help with. I want you to

basically be able to scrape this. I want

jobs that are sales opportunities or

sales jobs and I want to look just in

Europe. Scrape all of this. I want to

get like 500 jobs back and put it in a

nicely formatted Excel sheet for me."

Now, this time what I'm going to do is

we're just going to go ahead and do

bypass permissions. And like I said,

normally you want to go on plan mode.

You want to ask questions, but I just

want to show you guys what this might

look like with a pretty vague prompt and

just letting clog code go after it. And

hopefully it's able to do a better job

now because it understands how it can

scrape job listings and it has this tool

and it may even have to create a new

tool. So, let's just kind of let it run.

I'm going to analyze what it's doing and

then I'll report back once we see what

it actually ended up doing. And start

off by saying, cool. I have a scraping

tool from before that I can use. So,

here's my plan. I'm going to scrape the

sales jobs. I'm going to filter for

Europe and then I'm going to export it

all to an Excel sheet. It found 409

total sales jobs and now it has to

filter for Europe. And when it did that,

it basically found there's a limitation.

There's only 52 sales jobs in Europe,

but there are 409 total. So, let me

check if including worldwide would help

get closer to the goal. So, what's going

on here? It has our natural language

request, which was that we wanted 500

sales jobs in Europe. And it realized,

okay, this actually isn't going to work.

Let me brainstorm and see what else I

can do. And now you can see what it did

is it asked us a question because it

wants to help us reach our end goal

better. So it says, "Do you want me to

expand the search to get more jobs?" We

could either keep the 55 sales jobs in

Europe, we could broaden it to all job

types, or we could also do US-based

sales jobs. So I'm just going to go add

US jobs as well. And now it should keep

going. And hopefully now you can also

see why I wanted to give it a temporary

folder because in this operation where

it's running into a few issues, it's

creating some other temporary files like

all sales jobs, sales jobs raw. It's

also created three different Python

tools that are temporary tools just

because it knows that it needs some help

filtering things out. But now it was

able to find 372 sales jobs and it was

saved to sales jobs Europe and US. So it

says that we've got 372 sales jobs. I'm

going to open up that Excel sheet and we

can see if we scroll all the way down,

we should have gotten 372. Perfect. And

this is also similar because we can

filter up here with all of these

pre-made filters that it put in. We've

got job title. We've got all this

information. And it said that it added a

region column right here. And this is

where we could get rid of US and mixed

and worldwide. And we now should see

that we've only got about different

actual rows. Yeah, 49. And just as one

final test, let's see what happens if it

gets a crazy type of request that we

haven't really prepared it for. So right

now, this is good at scraping jobs from

a given URL. What if I just said, "Hey

Claude, I'm looking to reach out to tons

of dentists. Can you find me dentists in

the United States? And give me their

contact information so that I can

basically just build up a lead list of

dentists that I can contact. I want this

to be in an Excel sheet. I'm going to

shoot that off. Once again, this is in

bypass permissions mode. So, we're going

to see what it does. We're going to see

if it uses fire crawl. We're going to

see if it thinks about, hey, actually, I

can't use firecraw. I need to get access

to some sort of like, you know, lead

generation API or lead list API. We're

going to see what it does here. It said,

I can help you build a dentist lead

list. Let me first check what tools and

workflows exist. Then it says, let me

check the available APIs. So you have

fire call available and I can build a

similar tool to your existing job

scraper but for dentist leads instead.

All right, so look at this. It used

firecol to search for dentist directory

and then it started scraping those

sources. Once again, the ADA site uses

JavaScript to load results dynamically.

So the static scrape doesn't work. Let

me try a different method. So it found

out yellow pages works well. There are

3,000 dentists just in New York City.

And now I'm going to create a scraping

tool so I can actually do all of this.

Okay, so it looks like this is finishing

up here. And what you guys can see is

that it created a new workflow which is

scrape dentist leads. And it created a

new tool which is scrape dentist leads.

All right, we ran into another issue.

Only two dentists were found. The

parsing might need adjustment. Let me

check what was captured and then refine

the reg x pattern. So look how awesome

this is. It found the issue right here.

And now what it's doing is it's fixing

the tool. So it's updating the tool so

that it doesn't actually run into that

issue again. Okay. I mean look at this.

It said done. I've scraped 120 unique

dentist leads from four major cities.

Here are the cities we got. It includes

all of this data which is awesome. And

then it says for future scrapes, I've

also created a reusable tool that you

can run any time. So, I'm going to open

up that Excel sheet right here. And we

can see that we do indeed have all of

these different dentists here. It even

formatted the Excel sheet a little bit,

but we have phone number, we have

address, we have city, state, zip code,

websites, specialties, and we get the

actual listing URL as well. So, this is

incredible if you think about the fact

that I didn't know what tools to use at

all. I could have put this in plan mode

and I could have said, "Hey, this is the

workflow I want. Ask me questions, do

research, figure out the best approach,

and then I could have, you know, went

back and forth with a little bit and

this scrape might have even been better.

But on the very limited amount of

information I gave it, it still gave us

a really good output that would have

taken me so much longer to get manually

or building it in an end because the

truth is a lot of us know what we want.

We know the end result, but we don't

exactly know the exact tech stack and

all of the different things that we need

to get that end result. So why not let

an AI agent with a really smart brain

like Opus 4.5 figure that out for us,

look at five different approaches, and

then pick the best one. And the cool

part is you're not just limited to one

agent. You could open up five different

agents in here. As you can see, we could

just keep stacking agents on agents. And

then what I could do is I could just

tell all of them to try a different

method. So I could have four different

workflows running and then I could test

all four at the same time and whichever

one gives me the best result, I would

just delete all the other agents and

then stick with that main workflow. So

before we wrap up here, I actually

wanted to just contextualize one more

time what's going on. So let's take a

look at that first workflow we did. This

one was called scrape job listings. This

one says the objective is to scrape job

listings from daily remote.com based on

a search term. The required inputs are

search term, max pages, output path. The

tools to use are just this one, the one

that we created called scrape daily

remote jobs. And then it goes through

the exact steps and the exact outputs,

edge cases, error handling, all of the

stuff that I didn't tell it to do. It's

because of the framework. And it's

because it understands how to fail

safely. So that every single time

whenever we say, hey, I want you to

scrape leads from daily remote. It just

invokes this workflow, which inside of

it invokes the tool. So it's the exact

same thing that just happened for

scraping dentist leads as you can see.

So that's how simple it is to build an

agentic workflow. But before you go to

actually build one by yourself, you do

need to understand the mistakes that

most people are making right now.

Because understanding how to think about

these systems is what's actually going

to make it valuable to you. So the first

mistake is not being clear enough about

the actual goal. You can't just say, "I

need a lead scraper for LinkedIn."

That's way too vague. Agent will have no

idea what kind of leads you want, what

industry, what role. It'll just start

pulling random profiles. Obviously, it

can ask you questions, but you do need

to be specific about the problem that

you're actually trying to solve. And so

what you're going to want to do, as you

saw a little bit in the demo, is put the

agent in plan mode and say something

like, "Hey, here's a rough idea of what

I want. help me turn this into an actual

solid PRD or project requirement doc.

The agent then will have to brainstorm

and it will reason and it will think and

it will maybe even do research for you

and it will ask you all the right

questions so it knows exactly what to

build. Just like the way if you wanted

to give an actual human software

developer specs for an app or for a

workflow or whatever it is, you would

have to give them enough information so

that they could actually build that.

You're totally allowed to treat the

agent like the expert. You're just the

manager to make sure that you keep it on

the right path. So mistake number two is

not defining what done looks like.

Agents need to know when to stop. If you

don't give them the clear finish line,

then they may over complicate things or

break things or keep researching or keep

looping, keep iterating, and they might

just keep wasting time when the answer

was actually simple. I've definitely

seen agents overcomplicate a lot of

things. So, instead of saying, "Search

for LinkedIn profiles of CEOs at tech

companies," which is pretty open-ended.

Say something like, "I need exactly 75

LinkedIn profiles of CEOs at tech

companies. Put them in a spreadsheet

with their name, company email, their

link to their profile, and once you have

75, you're done." It's a clear input and

a very clear output, and that's how

you're going to get consistent results.

So now let's talk about why agentic

workflows are just better. First, no

more debugging loops. With traditional

workflow automation, you'd build

something, you'd run it, and then there

would be some edge cases that you didn't

think of, and that would break the

system. So then you'd spend the next

hour reading through the logs, looking

at the error messages, looking at the

execution data, and trying to figure out

what went wrong and why. With agentic

workflows, the agent basically handles

all of this for you without even asking.

You saw it earlier in the build. As the

agent was working, it would run into

some sort of roadblock or it would hit

an error and it would just say, "Okay,

this is what happened. Let me think

about what I could do differently." And

then I fix it. And then I update my

workflows and my tools so that it

doesn't happen again. It's basically

self-healing. And that's a massive

timesaver because this means that I can

have an agent on my right monitor

building stuff and then on my left

monitor I can just be doing different

work or maybe even watching a YouTube

video or catching up on my favorite show

and I've got cloud code right here

building things for me and all I have to

do is sit here and make sure I can poke

it in the right direction if I need to

every once in a while because at the end

of the day it is AI and it is not a

deterministic so it might veer off the

path a little bit. Second is natural

language control. With tools like ended

in you had to pretty much learn every

node. You had to know what each one did,

when to use each one, and what all of

the different parameters or settings

meant. If you wanted to connect to an

API, you had to read the API

documentation. You had to find the right

endpoint. You had to structure your JSON

correctly. You had to set up the

authentication. And that could be a lot,

especially when you are new to the

space. With the Genic workflows, you

just explain what you want, and the

system will look at all the tools

available, whether it has an MCP server

or not, or whether it just has to look

through and research the API

documentation on its own. And this is

absolutely beautiful. Third, it gets

smarter over time. So, I know we've

talked about this a lot, but it's just

so cool. If you wanted to update an

automation in the past, you had to go in

and you had to change the nodes and you

had to configure it manually. With

Agentic Workflows, every time the agent

runs into an issue, it learns and it

updates. Now, there is one important

caveat that I wanted to talk about,

which is the difference between

automations that you trigger yourself

versus automations that run on a

schedule. So, if I'm sitting at my desk

using Claude Code and I say, "Hey, you

know, we just had a call. Go ahead and

write up a proposal for client B."

That's a human triggered event in this

case and the agent's right there with

me. So, I can watch it, I can talk to

it, and that's how it's able to

self-heal in real time. But if you want

something to run on a schedule like

every morning at 6 a.m. or maybe an

event trigger like whenever someone

submits a form on your website or

something like that, that's actually

going to be you deploying that code, not

the actual agent. So the agent would

deploy its workflows and tools, but not

itself, not the cloud code model that

lives in VS Code. And the agent is what

actually makes the workflows and tools

self-healing. So you're not deploying

that. But anyways, I'm not going to dive

deep into that right now. That's a whole

other video. You can also check out this

video which I will link right above up

here where I go into pretty much that

whole process of building an automation

in cloud code and then actually

deploying it just so you guys can see

what that actually looks like. So look,

I know that this might feel a bit

overwhelming at first. The space is

moving really fast, but the reality is

that this is just the beginning. We're

definitely headed towards like fully

autonomous workflows, agents managing

other agents and systems that improve

themselves while you sleep. And the ones

who understand how to make them faster

will be ahead in this automation market.

So I don't want you to worry if you're

still learning how to make automations

or you're still learning end to end.

Your job isn't over and I think that's a

really good place to start. But now

we're just moving from builders to

architects. The key thing that matters

is how you adapt to new challenges. And

if you want to make it easier, you can

check out my free community with over

200,000 AI builders like you. And I put

everything that we talked about today

into a completely free resource guide

you can access in that community. Link

for that is in the description.

Cloud Code has been allowing me to build

things that used to take me hours in

just minutes. So that's exactly what I'm

going to be teaching you guys today.

Even if you don't know how to code and

even if you've never touched an IDE

before. IDE stands for integrated

development environment, but if you

didn't know that, it's still completely

fine. It's crazy how fast the technology

is evolving every single day. What used

to take people this long with manual

code was significantly reduced when

Eniden came out because we could drag

and drop nodes and build workflows that

way. And now that has once again been

significantly reduced with the release

of things like cloud code and

anti-gravity. Now, I'm not out here

saying that Naden is dead or that cloud

code completely replaces any. They're

slightly different. But I am going to

show you how easy it is to build

automations with cloud code today. If

you've never touched Claude Code before

or even watched a video about it, you're

in the right spot because my job is to

make confusing things as simple as

possible. So, in today's agenda, I'm

going to be going over the interface,

what do you need to know, because

there's a lot of stuff, but I'm just

going to tell you what's actually

important to understand. We're going to

go over the framework that we use to

actually build automations. I'm going to

talk about planning and the importance

of clear communication. We're going to

talk a little bit about the superpowers

that you can give cloud code like MCP

servers and skills. We're going to talk

about testing and how you actually

optimize your workflow. and then talk

about deployment, which means actually

kind of turning it on or pushing it into

production. And I'm not just going to be

talking throughout all of this. I'm

actually going to build a full workflow

in front of you guys and deploy it by

the end. So after this video, you'll

have everything that you need to go

build your first automation in Cloud

Code. And you're going to see how easy

it really is. All right, so we're just

going to jump right into it. This is the

interface. We're going to be using

Visual Studio Code, which has been

around for a long time. And if you go to

Google and type in VS Code, you can just

go ahead and go to this link and just

download it. It's free to download. And

then in here is where we're going to

actually be using Claude Code. So this

is what it should look like. What we're

seeing here is just kind of the welcome

page. You can see we can open new files,

new folders. We can do some of these

walkthroughs. But what I'm going to do

here is I'm going to go over to this

lefth hand side and click on extensions

and just type in Claude Code. And then

you'll see right here that this

extension pops up which lets us use

Claude Code inside of VS Code. So what

you're going to do here is go ahead and

install it. You could also do this in

anti-gravity or in cursor or somewhere

else or you could even use the cloud

code kind of app by itself and install

that locally, but wherever you choose to

use it, you're going to log in and then

we'll get started. I'm just using VS

Code in today's tutorial. It'll prompt

you to sign in with your Anthropic

account and then you'll be all set. Now,

in order to access Cloud Code, you do

have to be on a paid plan of Claude. As

you can see, if you're on the 17 bucks a

month plan with Pro, you get Claude

Code. Um, but you will probably find

pretty quick that you'll want to upgrade

to Max or the the higher version of Max

because you'll be doing a lot of

automations in there and you don't want

to hit your limit and then have to

upgrade. But you could always start on

pro and then upgrade later. So once we

got that extension installed, I'm just

going to go ahead and click on this

button in the top right which looks like

the Enthropic logo and I'm just going to

open up Claude Code. I'm going to close

out of this window and now you can see

that we have basically a chat GBT like

looking interface where we have Claude

code right here. So on the lefth hand

side, instead of looking at the

extensions marketplace, we're going to

click on this button up at the top that

says explorer. And what it tells us

right here is that you have not yet

opened a folder. So it prompts you to

open a folder. So before we go ahead and

open one up, let's talk about why and

what we're looking at. So this is kind

of the environment that we're looking at

right now. We've got our files on the

lefth hand side and this is where we're

going to actually build our project, our

system prompts, our workflows, our

tools. And then on the right hand side,

we have the agent. So this is where we

talk to Claude Code. We have it help us

with a plan. It asks us questions and

then it actually executes on those

actions. So lefth hand side is files,

right hand side is the agent. It's going

to be super simple and I'm going to show

you how we can keep our file structure

really clean so it doesn't get

overwhelming and confusing on this lefth

hand side over here. So whenever you're

in cloud code, you have to be working

inside a project and that's why it

prompts you to open up a folder. So what

I'm going to do is in my documents, I've

got a folder called agentic workflows

and I've got a bunch of ones that I've

been playing around and testing with.

But I'm just going to go ahead and open

up a new blank folder for today's video.

I'm going to go ahead and call this one

YouTube

analysis. And then I've created that

folder. So now when I go back into cloud

code, I'm just going to open up that

folder. Cool. So I just opened it up and

it changed what we were looking at over

here. On the right hand side, we've got

like VS Codes agent. So I'm not going to

worry about that and just close out of

that. And then on the lefth hand side,

you can see we're now in the YouTube

analysis folder, but there's nothing in

there yet. So once again, I'm just going

to reopen Cloud Code. close out of this

one. You can see you can have multiple

different files open on the right hand

side. So if you wanted to have like five

cloud code agents running or you wanted

to look at five different files or

system prompts, you could do so. But

right now we're just going to keep it

open to one. So the first thing that we

need to do is we need to give cloud code

a system prompt for this project. And

that's the first thing that you should

do whenever you open up a new project in

cloud code. And we call this system

prompt a claude.md file. MD just

standing for markdown. So I'll show you

guys that in a sec. But without a system

prompt, it's like we have an NN AI agent

like an expert copywriter and we don't

actually give it a system prompt in

here. So without a system prompt, it

wouldn't actually really be an expert

copywriter. It would be super generic.

It wouldn't understand the tools it has,

the product that we're trying to sell or

where the documents live and what those

look like. So that leads me into the

next part of the video, which is talking

about the framework, which is how we

actually build these automations. So

here's a really, really simple

visualization of what we're actually

doing here. We've got our agent which is

claude code and the agent is going to

help us build workflows. Workflows

meaning processes, SOPs, instructions of

what we actually want to do. And inside

those workflows, we're going to give it

access to tools. And tools means

actually executing actions. So send

email would be a tool. Research a

YouTube channel would be a tool. So it's

really similar to the way that we have

workflows and tools in Nitn. Here you

can see is an edit in workflow for a

daily news summary. And inside the

workflow, which is a specific set of

instructions in a specific order. So,

it's a deterministic process. We have

different tools. We've got a tool here

for Tavali to do research. We've got a

tool here for an AI agent to do the

newsletter writing. And we've got a tool

at the end to send a Gmail message. So,

hopefully that all makes sense. It's

going to be really simple. We're going

to have a folder for workflows. And in

there will be all of our processes.

We're going to have a folder for tools

and in there will be all of the actual

things that it can execute. And then the

agent basically helps us set up those

tool files and workflow files and then

execute those actions. So, I'm going to

do is drag in this claude file. And you

can see it's a claude.md. This could be

called agents.mmd, gemini.mmd, whatever

you want. In this case, we're using

claude code, so I'm calling it

claude.md. But let me go ahead and

expand this one and let's briefly read

through it so you understand exactly

what I just talked about with the

workflows, agents, and tools. So this is

the agent instructions for this specific

project. You're working inside of the

WAT framework, which stands for

workflows, agents, tools. This is a

three-layer framework and it basically

separates concerns so that the

probabistic AI handles reasoning while

deterministic code actually handles the

execution and that is what makes these

systems actually reliable. So like I

said layer 1 is the workflows the

instructions. So these are markdown SOPs

stored in the workflows folder which

will be created in a sec. Each workflow

defines the objective, the required

inputs, which tools to use, expected

outputs and how to handle edge cases.

It's written in completely plain

language the same way that you'd brief

someone on your team. And by the way,

when I say markdown, it basically just

means this structure. This is a markdown

file right here where we have like

headers and subheaders and bold font and

things like that. Layer two is the

agent. So this is the actual cloud code

agent that we talk to. This is your

role. You're responsible for the

coordination between workflows and

tools. You read the relevant workflow.

You run tools in the correct sequence

and you handle failures. You ask

clarification questions when needed.

Layer three, we have the tools, and

these are actually going to be Python

files. So right here, you can see claude

is a markdown file. So it's cloud.md. We

said that our workflows were going to be

markdown files. So it will be like um

scrape website.mmd.

But then in the tools which we will have

another folder for over here. We're

going to have tools that are going to be

py. So a python file. So in this case we

can see there's an example tool called

scrape single site. py which would be a

python script that would execute an

action. These can be API calls, data

transformations, file operations,

database queries. And a lot of times in

these tools, we'll need an API key, but

we're not going to actually store them

in the tool code logic itself because if

that got exported or we pushed that onto

the web, then our API keys would be

exposed. So, we're going to handle

secrets by storing them inv files. You

don't have to understand exactly what

that means or how that works right now.

We'll show you. So, then we talk a

little bit about like why this matters,

how to operate. So, you look for tools

first. You learn and adapt when things

fail because these agentic workflows are

basically self-healing. So, as we're

going through and building this

workflow, you will see that it says,

"Okay, I ran into an error here. Let me

figure out what happened and let me fix

it." So, fix the script and retest

document what you learned. So, if it ran

into an error and it fixed it, it will

go ahead and change the workflow file so

it doesn't run into that error again.

So, an example could be you get rate

limited on an API, you dig into the doc,

so you do research, you discover a batch

endpoint, you refactor the tool to use

it, you verify that that works, and then

you update the workflow so it never

happens again. This is once again where

we talk about that self-improvement

loop. We talk about the file structure

and you can see that it's going to

create this for us. And basically the

bottom line is that you sit between what

I want, which are workflows, and what

actually gets done, which are the tools.

Your job is to read instructions, make

smart decisions, call the right tools,

and keep improving the system as you go.

So, I know we skimmed through this kind

of fast, but you guys will get access to

this exact same system prompt. I'll

leave it in my free school community.

The link for that will be down in the

description. That way, you can just go

ahead and grab this, paste it in, and

then when you want to follow along and

build some workflows in Cloud Code,

you've got this right here for you. So

now what we need to do is just set up

our environment with the different

folders. So I'm going to talk to cloud

code and just say initialize this

project based on the claw.md file. So

I'll go ahead and shoot that off. And

when we talk to claude, what it does is

it basically just tells us exactly what

it's doing and what it's thinking. What

you'll notice right here is that I'm on

a mode called bypass permissions. And

you might not see this initially. You'll

see ask before edits, edit

automatically, and plan mode. But it is

really helpful to be able to turn on

bypass permissions. So the way that you

do that is you go to the bottom left to

settings. You're going to go to settings

once again. You'll type in cloud code

and then you're just going to turn on

this option that says allow bypass

permissions mode. And that's what allows

you to do that so that you can let your

agent run and you don't have to approve

every step. Now, as this is running,

what you'll notice is on the lefth hand

side, we're seeing some files and

folders pop up. So, we've got a

temporary folder, which just means

anything that it needs to store and then

like delete later just temporarily, it

can do so in there just to keep

everything clean. We've got our tools

folder, we've got our workflows folder,

and then we have av and getit ignore. So

this is going to help us just basically

keep our project clean, but also the

agent knows exactly where everything is.

Cool. So the project is now initialized

using our WAT framework and it showed us

what it created. So now let's move on to

section three of the video where we're

going to be talking about planning and

communicating with our agent. So what

I'm going to do is I'm going to clear

out this conversation. If I wanted to

access past conversations, I could do so

up here. I'm going to go to plan mode.

And this is really important. Whenever

you're doing something that actually

involves like creating something, you

need to describe the goal and you need

to be able to describe it super super

clearly. And it's not just the goal, you

need to also describe the features that

you want. And if you were to just

describe something and then chuck clawed

code at it and you would do bypass

permissions, you probably wouldn't get a

great output. So what you always want to

do when you're creating an idea is you

want to go on plan mode. Because what

you're going to see is when I'm on plan

mode, it thinks extra hard and it looks

at everything in the folder and it's

going to ask me tons of questions that I

might not have thought of, which is

really, really helpful because it gets a

really, really good understanding of

what we want and it brainstorms options

and then it actually will do it after

it's confident. So, let's explain the

workflow that we want to build today.

Hey Claude, I need your help building an

automation. I want this automation to

basically scrape tons of YouTube videos

and YouTube channels in my niche, which

is AI and AI automation. I want to get

insights about what videos are trending,

what's working well, and kind of what

the AI space is feeling like so that I

can create more content that people want

to see and that will be beneficial for

them. I need your help understanding how

we can actually get this data. So, look

into different APIs or MCP servers.

Also, let me know if there's any skills

that would be helpful because after

you've done this research, what I want

you to do is I want you to create a

slide deck for me. So, I want to get an

actual deliverable that will be sent to

my email using Gmail and it should be a

really nice professionallook slide deck

with charts and images and all of these

different graphics so that I can

understand what's going on in the

industry. So, that's what I've got. Let

me know if you have any questions or if

you have any recommendations for things

that I haven't thought of about this

automation system. Cool. So that was my

little brain dump and it's going to come

back and ask me a ton of questions which

is just going to help make this project

a lot lot better. And so I know a lot of

you guys might be looking at this and it

seems overwhelming and confusing and I

agree like when I first wanted to dive

into cloud code I watched some YouTube

videos and I just it didn't click. The

only way it's truly going to click is if

you get in here and you do it yourself

because once you send off these messages

just read everything it's doing. Read

every single line and you'll start to

understand the way that these models

think and what they try to do. And

that's truly the best way. So after this

video, restart it from the beginning,

open up Cloud Code, and just kind of

follow along with what I'm doing and it

will all start to click. I promise. And

by the way, you can see that as it's

making this plan for us, it's doing

research. So it's not just thinking,

it's also searching the web to find out

how we can scrape the YouTube analytics

and how we can use MCP servers and

things like that. Okay, so we got some

questions now from Claude. It says,

"What specific YouTube channels do you

want to track? Should I discover top AI

automation channels automatically or do

you have a list? Let's just go with

autodiscocover top channels. Frequency

is how often should this report be sent?

I'm going to go ahead and do weekly.

Then it asks us if we want to track all

this data in sheets. Yes, absolutely.

Let's do that. And then for delivery, it

says what email address should the

reports be sent to? And I'm going to go

ahead and say send to my Gmail. So, I

shut off those answers and now it's

going to keep updating the plan. All

right. So, the plan is finished. The

objective is to build an automated

system that scrapes YouTube data for the

AI niche. It analyzes trends and gets

performance metrics and then generates a

professional slide deck with charts and

visualizations and sends that to me over

Gmail. We've got the workflow which is

YouTube weekly report. We've got the

agent layer. We've got different tools.

It's going to build out these seven

different Python tools that it

mentioned. So fetching YouTube data,

analyzing YouTube data, generating

charts, generating slides, sending the

email report, exporting to sheets, and

discovering channels. And now it needs

to actually create this workflow. So, we

could obviously read through all of this

and we could give it some feedback if we

wanted to, but I'm just going to go

ahead and accept these because I want to

see how well it did with just one

iteration of our plan, which took me a

few minutes. So, you can see what it

does is it starts a to-do list. So, it's

basically just going to knock off one of

these at a time. And that's really nice

because it helps the agent stay on

track, but it also means that you could

go to your other monitor here and work

on something else and just kind of keep

peeking in on it and checking on the

to-do list to see how much is left to

run. Okay, so the to-do list is done.

The workflows and tools have been built.

So, here's where we're at. We've got our

seven tools have been created. So, if I

open up the tools folder, we should see

we now have these seven Python files.

And each of these, like I said, are

actual Python code that will execute

some sort of action. So, those have been

built. We've also got the workflow. So,

this is our markdown file, YouTube

weekly report, which is an actual

process. So, I'm not going to read this

whole thing, but it has the actual steps

that we would be doing here. So, now it

says to get started, we have a few

dependencies. So, the first one is we

need to install something. The second

one is to add a YouTube API key. The

third one is to set up Google OOTH for

Gmail and Sheets. And then the fourth

one is just to run the actual workflow.

So a lot of times when Cloud Code's done

and it has some action items, it

actually just tells you to do some stuff

that it could do itself. So right now we

would obviously have to go get our

YouTube API key and then we could just

give it to it and say, "Hey, you go

update the ENV. I don't want to touch

that. You just go do it." But first,

what it's doing is it's asking us to do

this. So, we could obviously just

install this right now, or I could just

say, "Can you please go ahead and

install the dependencies? I'll go grab

my YouTube API key." Cool. So, it went

ahead and installed that stuff just like

I told it to. And now it's asking for a

YouTube API key. So, instead of just

adding it to the file, I'm just going to

drop it in right here. And then the one

thing I will have to go do manually is

step three. So, I'll have to enable the

YouTube data API and Gmail and Google

Sheets and then create the credentials

and just drag in the JSON file, which I

will do that in a sec. And here's

another thing I'm doing with my API key.

It should only be added to the ENV file.

It shouldn't be listed in the workflows

or the tools. Okay, so I added

everything that I needed to. And if

you're confused about how to do that,

just say, "Hey, where do I go? What do I

click on? How do I do that?" And it'll

walk you through. And now what it's

doing is because it has all our

credentials, it's actually just testing

out if the things work. So you can see

the YouTube API is working now. Let's

run the full data collection pipeline.

So it's basically just testing that the

flow works and then we'll give it a full

run. But we can see that it just ran the

full pipeline. So that was our first

initial test. It found 30 channels. It

fetched 187 videos. It generated

analysis. It made six charts. It built a

nine slide PowerPoint deck for us.

Exported it to Sheets. And then it

emailed us the report. So let's go take

a look at all that. Okay. So here's the

email that I got. AI automation YouTube

analytics. So the weekly report for Jan

20. We got 30 channels tracked, 187

videos. We have some top videos from the

week. We have recommendations. And then

we also have our PowerPoint right here,

which we can see. We have similar

information. We've got median views,

median engagement, trending topics.

We've got top performing videos. So, we

have this laid out by title and by

views. We've got top channels by

subscribers. Unfortunately, I do not see

my name up there, so please hit the

subscribe button. We've got engagement

analytics. We've got trending topics, by

keywords in the Aming patterns, and then

we have some recommendations to kind of

close us off here. So, keep in mind this

is not perfect, and we obviously would

want to come back and make this a little

bit more tailored for us, but this was

one prompt. Cloud code asks us questions

and then I basically just sat down and

then I came back over here when it was

done and this is what we have ready for

us. What we also see is that we got this

exported to a Google sheet. So if I

click on this, remember that we didn't

create the sheet. We didn't create these

different tabs or the actual like schema

of this. But we've got three tabs. The

first one is channel stats. So this

pulled channel stats from today's date

which is January 20th. We have the

channel IDs. We have the actual channel

names. And then we've got subscribers,

total views, and video count. We can see

nice that Nate Herk AI automation did

make it in this scrape. We've also got

top videos. So once again, this was ran

based on today's analytics. We got the

video ID. We've got the title of the

videos. We've got the channel, the

views, the likes, the comments, the

engagement rate, which is pretty cool.

And also how old the videos are. So we

can see that we're getting real accurate

like what's trending right now. And then

we get a weekly summary. So this is

supposed to run every single week. We

can see the day that it ran, the

channels it tracked, the videos it

analyzed, the median views, the median

engagement score, and the top keyword in

top keyword 2, which actually, it's

funnily enough, spells out claude code,

which is why you're seeing this video

right now. Okay, so let's recap what

we've done. We have familiarized with

the interface. We have built out the

actual structure of our project using a

cloud.md file, which is like a system

prompt. Now, we have our workflows. We

have our tools and we have actually gone

through the whole planning stage with

claude code to build out the initial you

know workflow automation that we need.

So what comes next now is we want to

talk about a few other things. We want

to talk about superpowers. So MCPS and

skills and then we're going to test it a

little bit more and then we're going to

actually deploy the automation live. So

to start off with superpowers MCP

servers. So I'm not going to dive super

super deep into MCP servers in this

video but I did want to bring it up. So,

if you remember in plan mode, I

basically said, "Hey, I want to scrape

YouTube data. Can you just go figure out

if I should use an MCP server or like an

API?" And it ended up finding out that

the YouTube API was going to work

better. So, that's why we did it in this

workflow. But essentially, just think of

an MCP server as an app store. So, Gmail

has an MCP server, Calendar has an MCP

server, lots of these services do. And

this is like one of the most common

visualizations because it's like a

universal micro USB port because instead

of having to go to calendar's API and

have one different API request to create

an event, one different one to update

event, one different one to delete an

event, all we have to do is connect once

to the whole server and then the agent

can figure out how to go use different

endpoints and parameters. It just

simplifies the whole process. Now, what

I did want to talk about a little bit

more was the idea of claude skills

because this is a little bit newer. So

essentially skills are instructions or

resources that Claude can load in

dynamically. And that's kind of the key

piece here is that instead of just

reading it every time in a system

prompt, it basically understands what is

the request. Let me go look at all the

skills I have access to. If one of them

is relevant, I'll pick that one. I'll

read it all and then I'll take action.

And this process basically just improves

Claude's consistency, speed, and

performance. And also saves you tokens.

Like I said, when you ask Claude to do

something, it reviews the available

skills. it loads in only the relevant

ones and then it applies those

instructions. So, we're going to go

ahead and try to implement a skill into

this workflow and I'll actually show you

what the skill document entails. So,

then it will all start to make a little

bit more sense. But before we do that, I

did want to real quick cover the

difference between skills and projects

and skills and MCP. So, the first one is

about projects. You're in a project and

basically what we have is access to

whatever is in here. So, it's kind of

static documents and background

information. And a lot of times these

skills are installed globally. So what

you'll notice actually in our project is

that we don't have any skills in this

project. Normally there will be like a

thing that will be like agents and then

you drill down in that folder and you'll

see like agent skills or claude skills.

And that's more installed on the global

level. And that's actually really good

because what that means is if I closed

out of this project and I opened up a

different one, I would still have access

to all the same skills that I've already

installed. So you can see right here

that I just asked Claude Code, "What

skills do you have?" and it came back

and showed that it has a front-end

design. It has naden skills and those

are the only eight that it actually has

even though we don't see them in this

specific project. Now we have skills

versus MCP and these are also very

different. MCP is basically to get data

and take action. So like I said if you

want to connect Claude to something like

Gmail to read emails or to send emails

but skills are more like knowledge

custom instructions. So, if you ever

find yourself constantly repeating

something to your cloud code agent, then

maybe that's a good sign to put it

either in the claw.md file or create

your own custom skill for it. So, like

the example of the front-end design, if

you wanted to use cloud code to build

yourself a landing page or a website,

using the front-end design significantly

improves its ability to actually design

things. So, what we're going to be doing

in this example now is I want to use a

skill and I'm going to be looking at

this cloud code templates website which

has a bunch of agents and commands and

MCP servers and skills and hooks and I'm

going to be looking for one that helps

us create like better looking PDFs. I'll

also leave a link to this in the

description of the video. So, I went

ahead and searched for design and you

can see there's a skill right here

called canvas design. And if I view

details here, it says create beautiful

visual art inputs

using design philosophy. So, we're going

to go ahead and try this one out. I've

never used it before. We'll see how it

works. But this is actually like the

code of the skill itself. And you can

see it basically is just natural

language instructions. So, it's just a

custom prompt that someone built or you

built yourself. And now I can load this

into cloud code. So, when we have it

design a PDF, it can use this and it

will probably just come out a lot better

because it's prompted. So, we've got

installation right here where we can use

this code. So, what I would try is just

copying this, going into VS Code. I'm

going to go ahead and open up a, you

know, kind of clear the conversation and

just paste that in and see what happens

if I drop that in there. Okay, so I

dropped it in and then it actually ran

the command in our terminal to install

it. And it says that it's been installed

and we have skill.md for the

instructions for the skill. And then

we've also got a bunch of fonts. And

what it did is it actually created a new

folder here called.claude. And then we

do have skills right here. So you can

see that it put it in this project. So

now I'm a little confused because I

don't know. Okay, we have a skill here,

but we also have skills globally. So I

would literally just say it looks like

you created this skill in this project.

Is this going to be installed globally

or will it only be accessible through

this project? So right now it basically

says yeah this was installed just

locally in this project and that's fine.

And if you wanted it to be global

instead you would just say okay actually

just make that global and then it would.

So anyways going to clear out this

conversation one more time. I'm going to

go back into plan mode and I'm going to

give it a prompt. And actually one more

thing before I prompt it. I'm going to

drag in the AI Automation Society Plus

logo just over here on the lefth hand

side. And you can see it's right here

and the file pops up. Right. So, what

I'm going to do is prompt it, but I want

it to actually have this logo on all of

the PDFs that it generates. Hey Claude,

so I just gave you a skill for canvas

design. And instead of outputting a

PowerPoint presentation, I want you to

now take the same research when you do

your analysis from YouTube videos, but I

want you to use that canvas design skill

to create a PDF. It needs to be

professional, but it needs to be

aesthetically pleasing. And what I want

you to do is make sure you're including

the AIS Plus logo PNG that I dropped in

this folder as well because I want the

whole presentation to be branded so I

can share it with my team. So, I'm

shooting this off in plan mode and I'll

let you know when it comes back with

some questions. Interesting. So, it came

back and said that that canvas design

skill that we just installed creates

PDFs interactively, which means step

five of our workflow changes from fully

automated to semi-automated. So, how do

we want to handle this? Let's just go

ahead and just say keep it fully

automated because that's kind of the

whole point. We want to be able to push

this live to run on a schedule trigger.

Okay. So, the new plan is to replace the

PowerPoint output with a branded PDF

report. So, it's going to make a new

tool to replace the generate slides

tool. We have our current workflow

state. We've got our logo. It has some

proposed changes here. We're going to be

looking at the PDF structure. And of

course, what it has to do is update the

actual workflow. So, it's going to look

at this YouTube weekly report markdown

file, which is the actual workflow. Of

course, it's going to change that. It's

going to update some of the other tools

like the email tool. And then, of

course, it's got some other

implementation steps for us. And in this

case, what I'm going to go ahead and do

is just autoaccept these changes. And

so, right now, it's just setting up a

to-do list to actually implement those

changes. We're not going to be running

the workflow again. We're just going to

make the changes, and then we'll go

ahead and test it. And just a reminder,

when you guys are in here building your

own workflows, just pay attention to

what it's actually doing. It does some

really interesting things. Like right

here, it installed some dependencies to

actually be able to create the PDF a

little bit better. And then here it says

the PDF was generated, but it's using a

fallback using whatever this is, and it

would look better if it had proper title

and closing pages. So, it's going to

install something else and then try it

again. It's just a reminder of using

this framework of an agent that sits

between workflows and tools. As it's

building them out, as it's testing them,

it's continuously improving them, seeing

errors, seeing things that could be

improved, and then just going ahead and

doing that for you. So, that's where

it's really powerful. And this testing

and optimization phase is really

important because once you actually

deploy your automation, you're not

deploying the agent. You're just

basically deploying the workflow that's

connected to tools. And that's important

to understand. The workflow itself would

be put up into the cloud where it could

run on a schedule trigger, but the agent

still lives locally in cloud code. Which

means if a workflow which means if your

workflow is running every week, it's not

going to be self improving and

self-healing. So if you wanted to do

that, you would come over to cloud code,

you'd edit the workflow, you'd improve

it, and then you just push that version

back to modal or wherever you're hosting

them. But anyways, this finished up, so

it created a new tool. It modified a few

other things. It changed the actual

workflow itself. And then what also it

did is it made a test PDF just to see

how that worked. And you can see here

it's stored as a temporary file. So in

our temp folder, which is right here,

you can see right there we have a

YouTube report PDF. And let me just make

this bigger. We've got our logo right

here. We've got our AI and automation

YouTube analytics report and we have the

thank you slide. So it basically just

tested to see if it worked. But now

we're going to go ahead and run that

full workflow and then we're going to

see if we're ready to actually push it

up into production. So I'm on bypass

permissions and I'm just going to shoot

off run the YouTube analysis workflow

and it's not even called that, but it

will be able to search through the

workflows that it has and it's going to

understand which one to run. It's going

to execute all of those Python scripts

in order and then we should have a

finished product. Okay, so here's the

email. It has the similar structure as

far as the actual body of the email, but

then at the bottom, we should have our

PDF, which we got attached right here.

But what you'll notice is that it's only

two pages. So, it didn't actually create

the right type of PDF that we were

looking for. However, it did update the

Google sheet. So, it added, you know,

those 30 more videos that we originally

didn't have on this sheet. It added more

videos, of course, and then it threw in

one more weekly summary where it has a

little bit of a different metrics. And

what's interesting is that you can see

that it did generate charts and it did

do analysis because it actually

generated all of these images over here,

top channels, top videos, key

performance indicators, posting

patterns, all this kind of stuff. It

just didn't actually include it. So once

again, we would go back in natural

language and say, "Hey, you know, we

just got that PDF, but it was only two

slides." So what I did is I said

everything seemed to work except for the

PDF that I received was only two slides.

It was only the title and the thank you

page. So, it found the issue. It fixed

it. It changed the workflow. It changed

the tools. And now, it's shot me off a

new example with nine pages. And this

time, we still have the logo. We still

have the date. And we also now have all

of the actual slides that we need in

this PDF with the charts and things like

that, recommendations, and then we still

have the closing off slide. So,

hopefully you guys understand now how

important the planning really is because

we did kind of rush through this in this

example where we auto accepted changes

and we just kind of like sped through

things. And it's fine because we're

still able to go back and forth and let

Claude Code investigate and fix, but it

should show the importance of if you are

really really clear up front and you

know exactly what you need, it will be a

lot better off the jump, but it's not

perfect. Okay, so now let's say we're at

the spot where we're ready to basically

make this workflow live where we

actually want to forget about it and

just let it run every Monday at 6 a.m.

or whatever. So, we need to deploy it.

So, the way that we're going to do that

is we're going to use modal, which is AI

infrastructure that developers love.

Essentially, what modal is is it lets

you spin up these kind of like computers

in the cloud where you can host your

automations and it only charges you when

they actually run. So, you're not

getting charged by the minute or by the

day. You're only getting charged every

time they actually execute. So, when you

create an account, you'll get five bucks

for free. And then if you add a credit

card, even though it won't charge you

yet, you'll get 30 bucks. And this 30

bucks will last you a long, long time.

Trust me. So, what'll happen is this

screen will probably pop up and it will

say that you need to download and

configure the Python client. So you

could basically copy this exact command

right here and just put that into cloud

code or you could just say hey cloud

code I want to push this workflow to

modal. So just help me get that

initialized. But I'll just show you what

would happen if you copied this and we

came into cloud code and said awesome I

want to push the YouTube analytics

workflow to modal so that it can

actually run every single Monday at 6

a.m. And then I'm going to go ahead and

paste in those two things that we just

saw. And let's actually do this in plan

mode first and just shoot that off. So

what it's doing is it's going to read

through the workflow structure and the

tools and understand how it can package

everything up so it can actually deploy

it on modal as an app. So it came back

with a plan to deploy this on modal. But

there's one more thing that I want to

ask it about before we actually do this.

And this last part is security. So I

basically told it to run a security

review and make sure that my API keys

aren't exposed and that there's no

vulnerabilities because the reality is

we just built a ton of code and I don't

know what the code is actually doing.

So, it's really important to be thinking

about this before you put anything out

there on the web. Are any web hooks

exposed? And if they are, do you have

like, you know, proper protection around

that? Are secrets out there? Are API

keys out there? What could people do now

that this is out there? And as you start

to deploy more workflows, whether that's

an NEN or whether that's in code like

this, you'll start to understand the

things to look out for. But you also

have one of the smartest reasoning and

coding models right here in front of

you. So, you might as well just ask it,

hey, check the code and let me know if

there are any risks. So the security

review came back and it found three

critical issues that need attention. But

the good news is nothing is vulnerable

and there's not a GitHub repo. So

nothing's been committed out there

publicly and everything is going to be

stored as a modal secret. So the API

keys and the JSON token. So nothing will

be committed to any repository. So we're

good to go. And basically from there it

came back with a plan once more and I

have approved it. So it's going ahead

right now and it's creating the

different tools and the different things

that we need to actually be able to

write this over to modal and then we'll

go ahead and test it out over there. So

our deployment is now complete. It had

to update the scripts to make sure that

they could actually have the right

environment variable path. It had to

create a modal deployment file. So it

actually just understands the process of

what it just did and schedule the cron

or the schedule trigger. And then it had

to create modal secrets that we could

store over there. So it is now deployed

and scheduled. So if I click on this

link, this will bring us to our modal

environment right here. And what you can

see is that we have two different apps.

We have the analytics and then we have

the analytics manual. So it had to do a

manual run just to see if it worked. So

this is the actual app. So if I go back

to the main dashboard, you can see that

we have this app and there's kind of

like the two different like endpoints.

But if I open up the app, we can see the

overview. We can see deployment history.

So as you change something in cloud code

and then push it back over here, you'll

see a different version. And then you

can also see the app logs when it's

running. So, when I click into the

YouTube analytics one, the one that will

be live, it says the next run will be in

5 days. So, it's scheduled at 6:00 a.m.

only on Mondays America Chicago time.

But what I'm going to do just to prove

to you guys this is working or at least

test if it is working is we can actually

just go ahead and run one right now. So,

I scheduled an immediate run. We're

going to see this pop open right here

and we're going to see the fact that

it's running right now. As you can see,

it took 2 seconds to start up and now

it's running. And then we'll see the

result of that execution. And actually,

I'm glad that this just failed cuz I can

show you what you need to do. But this

failed, right? So we'll click into this.

And when you click into each of the

runs, you'll basically be able to see

the logs and the executions. So in the

log, this is what actually shows us like

why it failed and what happened. So I

don't really know what this means,

right? All I'm going to do is copy this

entire string of text. We're going to go

back into cloud code and I'm actually

going to go ahead and clear this because

we're at 64% context. So just going to

restart fresh. So, I just tried to do a

manual run of our YouTube weekly report

app in modal and this is the error that

I got. And then I paste in all that

messy stuff and shoot it off. Okay, so

because we tested so much and we were

using the free tier of the YouTube data

API, we actually just hit the daily

limit, which was about 10,000 units and

we exceeded that because we were doing

so much testing to see how well this

thing would work. The good news is if

this is actually running weekly, we will

never hit that daily quota limit. So,

we're fine. But the bad news is we're

not going to test this one right now.

But at least it does suggest other

options and some longer term fixes. But

it's okay because I did want to end off

by showing how you could deploy

something with a web hook trigger rather

than a schedule trigger. So what I did

is I came into this other workflow that

I built the other day which is a very

simple lead web hook notification. So it

has a web hook as the trigger. We would

see a company name and some other data.

We would research the company with

Replexity and then send an email

notification. And so I basically just

said, "Hey Cloud Code, can you push this

workflow onto modal as we did earlier?"

And now we have this app in our modal.

As you can see, lead-web hook. So what

I'm going to do is go to Postman. So we

can actually hit that web hook just to

simulate what would happen. We've got

the address, we've got the body, and

I'll shoot this off. And what this is

going to do is it's going to trigger

this form endpoint in modal. So I'll

click into that one. And you can see

right now we have a status of pending.

This one's going to start running. And

then it will show that we actually get

the email in Gmail. And so this is

really just to show that once you have

your stuff up and running in modal, it

will work. And you can also do it based

on web hooks rather than just doing it

on a cron. So that looks like it

finished up. We can see that we just got

this email for the new lead Chipotle

where it did some research about them

and then obviously it gave us a

notification here. And now what you

could do is because you just went

through the process of deploying a

workflow to modal and you know that it

works because you just validated that

it's working. You have all of that

history right there. And what you could

do is say, "Okay, cool. Keep this stored

either in my claw.md file or let's

create this as a skill so that every

time later when you're building a

workflow and you want to actually push

it to modal, you have all that

information already there, whether

that's a skill or whether it's in the

system prompt of cloud.md." So, I hope

you guys at this point can see how

Claude Code makes this stuff really,

really easy to get automations up and

running. Whether that means an

automation that you want to be there for

and you trigger kind of to use as like a

personal assistant or an automation that

you actually want to host somewhere and

have it run on some sort of trigger and

you can tap into all the skills that

other people have been building and

using because you can find those

publicly and then just add those to your

own instance. So now you have the super

smart model like Sonnet 4.5, Opus 4.5

paired with all of these really good

prompts and really good like MCP

servers. So you can pretty much do

anything in that environment. The more

you start to use it, the more you'll

realize that you don't have to actually

switch around to a bunch of different

Chrome tabs and different apps on your

desktop. You can do a lot of the stuff

that you need to do just in the cloud

code environment itself. So once again,

that claw.md file that you guys can

access for free will be in my free

school community. The link for that will

be down in the description.

So I've been using Cloud Code for a

while now, and I opened up trigger.dev

for the first time, I'm not kidding you,

like an hour and a half ago, and I've

already got a couple really nice

automations and agents set up. I can

already tell that this combination is

going to be a core piece of my workflow,

whether it's internally or for clients.

And this combination of Cloud Code and

Trigger Dev, is insanely powerful. So,

the first thing I tried was just

building a workflow to scrape Nate B.

Jones YouTube videos. He's like my

favorite AI news channel. And it would

check if he's got a new video. If yes,

it would give me the key highlights. If

no, it would do nothing. And so, this is

what the result looks like with minimal

prompting. We've got the YouTube video.

We've got key concepts, quotes worth

remembering, stats, and data. So that's

cool because I spun this up in like 10

minutes, but really it's not that

impressive. But then I thought to

myself, because of the way that

trigger.dev works, I want to put an

agent in the cloud. So what I did is I

built an agent that watches this list in

my ClickUp. And whenever I put in a

company as a task, it will basically do

research about them. So I put this in,

it triggers the agent, it does research,

and then it comes back and leaves a

comment for me. But not only that, but

the agent can also conversate with me in

here. So this one for Enthropic, I said,

"Hey, does this company have a recent

valuation?" And it did more research and

came back to me. So, this is not just a

deterministic 1 2 3 4 5 type of

automation. This is a non-deterministic

I have different tools. I need to decide

what loop I need to go in. And that's

where I was like, okay, wow, I just did

all of this in like 20 minutes. This is

cool. So, by the end of this video, you

will understand exactly how you can

build workflows and agents in cloud

code, put them on trigger.dev, and

automate pretty much anything. So,

before we jump into building, let's just

get on the same page. We use cloud code

to describe what we want in plain

English. This could be saying something

as simple as, "I want to monitor YouTube

for new AI videos and send me a daily

summary." Cloud Code will then say,

"Okay, well, to do this, I need X, Y,

and Z from you." So, it turns a vague

request into an actual working

automation. Then, it goes ahead and it

starts writing its code. And like I

said, these can be simple tasks like

fetching data from an API, or they can

actually be kind of complex agents that

have different tools and have different

actions they can take and they have to

decide when is good enough. And that

actual automation or that agent is code

and that is basically a project and

that's like a file. And then what we

need to do is get that out of our local

cloud code environment on our laptop or

our desktop and put that into

trigger.dev on the cloud so that these

can actually run all the time. And so in

past cloud code videos, you might have

seen me use something like modal. So why

are we using trigger.dev over modal

today? It's just a lot more flexible. It

has scheduled runs. It has automatic

retries. It's got queuing. It's got

orchestration, which is the element of

different tasks and things like that,

which is really cool. And I just think

it's got a much cleaner UI as well. So,

here's my current project in trigger.dev

in production mode. And you can see that

I've got basically these six different

kind of tasks. These three are the

actual tools. So, this is the process

video. This is the responder agent. This

is the researcher agent. And then these

ones with a clock next to them are

schedule tasks. So, we've got the

YouTube checker, we've got the research

polar, and the follow-up polar. If I go

over here on the lefth hand side to

schedules, you can see how often these

run. So these two run every 2 minutes

and this one runs every 8 hours. If I go

to runs, you can see all of the

different runs that we've had, whether

they have been completed or whether

they've failed. And so I filtered to

show you a failed run because I wanted

to see the retry. So this was a ClickUp

research polar and what happened was it

failed and so it adds a delay and then

it tries again. So it has this automatic

retry built into it which is really

cool. And when we're watching these

agents or tasks run live, we see exactly

every step that they're making and we

see how long they take on each step. So,

I'll do a live demo and I'll show you

guys this. All right, so I'm in my

ClickUp and what I'm going to do is add

a new task and I'm just going to go

ahead and say Nvidia and I'm going to

save that. And now that that has been

processed, we're going to have to wait

in here and we'll see the ClickUp

research polar start up and then it will

basically say, "Okay, cool. I found a

new task and I'm going to send that to

the company researcher agent." So right

here we can see that that got picked up.

It got sent to the researcher. And if I

open the researcher, which is currently

executing, you can see it live running.

So we can see right here that it's

running for Nvidia, which is the one

that we just put in here. Right now,

Claude is calling its search web tool,

and it called it twice. It actually

decided I'm going to invoke it one more

time to make sure I get a comprehensive

research report. Now it's using a read

URL tool. It's using another read URL

tool. So maybe it found two websites to

look at. And there we go. After about 45

seconds, it has finished. So now if I

open up ClickUp and we go to Nvidia, we

can see that this is now marked as

complete. And when I click on it over

here, we can see that we got a full

research brief about Nvidia. And so now

if I come into this task and I say at

UPAI, how is their stock doing? It's

going to read this. But keep in mind, it

has to come in here and it has to read

the context to make sure it knows who is

they in this case when I just said how

is their stock doing. And if I go back

to runs, you can see that the follow-up

responder is now executing. If I click

into it, we should be able to watch it

actually looking at this task searching

the web. And now after about 22 seconds,

this one has finished. I'm going to open

up ClickUp. And we should be able to

scroll down and see that we just got a

response right here from Upet AI. Okay,

so just a little quick demo and wanted

to show you guys what trigger.dev looks

like before we actually get in there and

we build one out ourselves. And I know

these aren't the most impressive things

in the world, but keep in mind all of

these were oneshot prompted and I built

these in the past like 45 minutes. Okay,

now hopping into cloud code. This is the

cloud workflow builder project that I

just set up and I started building these

workflows in. If you've never used cloud

code before, then I would definitely

recommend you hop over to this video.

I'll link it right up here. And then

once you understand like the interface

and how the files work and everything

like that, then come back and it will

make a lot more sense.

So, what I'm going to do in this video

is I'm going to create a brand new

project and walk through everything with

you guys step by step so you can see

exactly how it works. But real quick

before we do that, I just wanted to show

you kind of what this end result looks

like. Because these folders and files

build up as you build more workflows.

Really, the main thing that I wanted to

show you guys is where those TypeScript

files actually live, which is right here

in a SRC. We've got the trigger folder,

which is trigger.dev, and then I've got

two different folders for the different

types of workflows. We've got the AI

news digest, which is the two, you know,

the process video typescript, and the

YouTube check type script, which you

guys saw right here. YouTube check and

process video. And then we have the

company research ones, the two polars

and the responder and the researcher

agent, which you guys saw right here,

the two polars and the researcher and

responder. So really what I wanted to do

there is just contextualize for you guys

how cloud code helps us build these

TypeScript files and then we push those

to trigger and then they can actually

run live. But I did promise you guys

we're going to do all of this together.

So I'm going to go ahead and open up a

new folder here. I made a new folder

called trigger demo and it's completely

blank. And now you guys should have your

Claude Code instance looking exactly

like I do. And by the way, I am using

this in VS Code. So I'm going to close

out of this stuff. Open up Claude Code.

And we are now on the same page. So the

first thing I want you to do is go over

to my free school community. The link

for that's down in the description. Go

to the classroom. Go to Claude Code and

go to the trigger.dev section right

here. And you're going to grab the

claw.md file and the trigger ref.md

file. You're going to download both of

those. And then you're basically just

going to drag both of those in to the

lefth hand side right over here. I'm not

going to dive super super deep into

this, but the trigger ref file is

basically like the trigger.dev API

reference and how to do TypeScript. And

that's important because in the bottom

of the claw.md file, we tell it to look

here if it ever needs to look at code

examples, patterns, and things like

that. So now that you guys have the

claw.md file in here, you've got the

trigger refile in here. We're going to

be able to build automations a lot

easier now. All right. So, what I'm

going to do is give Cloud Code a pretty

vague request. I'm just not even going

to use plan mode, and I'm going to show

you how good it's going to be. I need

you to build me an automation that's

going to go off every single Monday, and

it's going to search the web, and it's

going to find me um leads. It's going to

find me dental practices that I can sell

websites to. So, I'm going to shoot that

off. And what it's going to do first of

all is it's reading the claw. I'm

defiled to figure out what its goal is.

And hopefully it should come back and

ask us some questions so that it knows

how to build this workflow well because

we didn't tell it anything about text

stack or hardly anything at all and it

needs to write this automation really

well for us. So the first thing it does

is it asks us where should the leads be

delivered each Monday and I'm just going

to go ahead and say ClickUp. For

location it says where should it be

searching? I'm just going to say

nationwide. And then the final one is do

you have SER API, Google Maps, anything

like that set up? And I'm actually for

this one going to click other and I'm

going to say I don't yet have any of

that set up. And ideally I don't want to

have to pay for any sort of subscription

for this. And we'll see if it can figure

it out with that. I'm going to tell it

to create a new list in my ClickUp. And

for volume I'm just going to go ahead

and do 25 leads small batch just to

start. Now mine is going to cheat a

little bit because in the past it's

already used my ClickUp. But what you

would need to do is it will basically

create you av file and you will put your

project secrets in thatv file. So that

will be like your ClickUp API key or

your workspace ID or your open router

API key, things like that. So now it

asks us if we're ready to build this

plan. So we have our Monday dental lead

generator. Every Monday at 8 a.m. we

will search Yelp Fusion AI for dental

practices across the US. And then we'll

create new tasks in the dental leads

list in ClickUp. Yelp Fusion's 100%

free. Awesome. For the architecture,

it's going to create basically two

different tools. Let's call them. The

first tool is going to find leads and

the second tool is going to create the

leads in ClickUp, which is great because

if one thing fails, it can retry and it

can, you know, ceue up just that one

task rather than having the whole

automation break. And this is awesome.

It's automatically doing the item

potency like I talked about earlier. And

it's making sure that the same practice

never gets added twice. And having this

dduplication process be automatically

taken care of is really nice. So, I'm

just going to tell this to go ahead and

start building. So, as usual, it starts

setting up the project, as you can see,

as well as it is creating its to-do

list, and it's going to go through and

build this out for us. Okay, it built

that really fast. It said that it made a

new ClickUp list for us, which if I go

to ClickUp, we can see right here, we've

got dental leads. It created the two

type scripts. So, if I look up here,

we've got trigger, we've got dental

leads, and we have create lead as well

as find leads. And this is the part

where I said it cheated a little bit

because it already had our list ID from

earlier. But what we need to do now is

go get our Yelp API key. So, I'm going

to go grab that. And then we need to put

in a ClickUp API key. Wow. So it ended

up finding out that Yelp killed their

free API tier. So it's going to change

this to use SER API instead. Okay. So

now it's already changed that to use SER

API. So I've got those two API keys. And

here's what we're going to do. We're

going to go to the ENV and you can see

that it's put this placeholder in here

for SER and for ClickUp. So you're going

to come in here and paste in your two

API keys. And then you're going to make

sure to save this file and then you can

close out of it. Okay. So it wants to do

its test run in the dev environment in

our trigger.dev. So remember we're in

production. We can also be in dev. So

this is where we can test things. This

is where we can make changes. And then

when we're good with that, we push that

to production to actually be live. So

what I'm going to do is in my

trigger.dev, I'm going to open up a new

project since this is what your guys

would look like. We're just going to

call this one test. And I'm going to go

ahead and create that. Now once we're in

here, I'm going to go down to the bottom

and go to project settings. And right

here we see a project ref. So I'm going

to copy this value. And we need to give

this to Claude Code so it can actually

move stuff into here. Okay, so it's

working away right now, but you can see

that we do have two tasks in here. We

have our find dental leads and we have

our create dental lead. If I go to

schedules, we should see that the find

dental leads runs at 8 a.m. only on

Mondays. And now what it's doing is it's

going to try to test it out to see if it

actually works. But what's going to

happen is it's probably not going to

work because if you guys remember, we

had to give Claude code here our env,

you know, ClickUp API key as well as

that SER API key. But those API keys

don't actually get pushed anywhere. They

don't get pushed to GitHub. They don't

get pushed to trigger.dev because

they're in AENV file. And if anything

here has a dot before it, it's basically

hidden from like commits and stuff like

that. So what we actually have to do is

we have to go into trigger.dev. We have

to go all the way down here to

environment variables and this is where

we add those once again. So I'll click

add new and all I have to do actually

it's really simple is I come into thev

file over here. I can copy this entire

thing and then when I go back into

trigger I can paste in that entire thing

and all three of those will get put in

not just like having to do that one by

one. And now before you save this you're

going to want to do it in development

and production because there's no point

in adding it just to development because

ultimately you're going to push it to

production. So you might as well just do

development and production and then go

ahead and save that. And now trigger

when it's actually running those

Typescript you know files it can

actually use these API keys in its work

and it will actually be successful. So

what happened was this was trying to

actually trigger a test run in trigger.

So it was trying to do this by itself.

But one thing that you can do to make

this actually a lot better is you can

give it the trigger.dev MCP server. So

here's a file that you can drag into the

lefth hand side. It basically just sets

up the MCP configuration for

trigger.dev. And I will also link this

in the same exact classroom section

right here. So you can just download it

and drag it in. But now I can go ahead

and ask it to try to test it out again.

And hopefully it works and it can send

over a payload and all that kind of

stuff. And the thing I want you guys to

understand too is yes, I just did this,

but it it's a little bit different every

time you build it because ultimately

what's happening is we're talking to an

AI model that thinks and has decision

capabilities. So, if you're entering in

the exact same prompts that I am, you

might not get the exact same result. So,

it's really just a matter of talking to

it, asking what's wrong, and helping it

out. And so, now it's asking us for a

trigger.dev secret key. Well, let's go

into trigger.dev. Let's go over here and

go to API keys. And we need to grab this

and give that to cloud code. But, of

course, I don't want to give this

straight into the chat. So, I'm going to

say, "Hey, I've got this. Can you put a

placeholder in thev?" And then I'll

paste it in there. It's really just best

practice to never give secrets right

here in the chat. You want to just put

it into like config files or usually the

EMV. Okay, so just paste it in that API

key. I've saved it and now let's see if

it can actually restart the server and

try to test out our workflow. This is

why it's so tough doing like live cloud

code demos. It's just cuz like it

literally runs different every time.

Okay, so it says that it triggered a

run. Now, if I come back in here and I

go to runs, we should see. Wow. Okay, so

we actually got a lot of different runs

come through. It was trying a lot of

different things. These are currently

executing right now. Oh, okay. Well, the

reason why it did so many is because it

had to do one create dental lead for

every single lead that it found. And if

I open up my ClickUp, we can see that we

do have 25 leads right here. So, let's

just click into one to see what it looks

like. We've got Tampa Dental in Tampa,

Florida. And in the description, it gave

us the address, the phone, the rating,

and the website. So, that's really

interesting to me. The first workflow,

which is the trigger, it finds the

leads. So, if I open this up and I click

into it, we can see what it did. It

found five and then it found five more

and it found five more until it got to

25. And then after it found those 25, it

basically said, "Okay, cool. I'm going

to hand each of these leads to one

individual kind of like worker." And

that is why we saw the create dental

lead tool get called 25 times. Cloud

code comes back and says, "Cool, it

works perfectly. 25 leads created in 9

seconds across five cities. Pretty

awesome." So from here, obviously, what

you do is you'd iterate upon the

workflow a little bit. You'd try to make

it better and better. You'd add

different features if you want. Maybe we

want to add personalized outreach and

add like an AI element in there. But now

once you get to a spot where you're

ready, we want to push that into

production because right now we're in

development. Meaning if we don't keep

this connection open right here, it says

your local dev server is connected to

trigger.dev. If this wasn't open like we

see in our main project right here, you

can see I turned it off. Then these

would not be running, which is why we

have to push them to production. So

there's a few ways to do that. So the

way that I would recommend doing this is

by connecting to GitHub and pushing your

codebase. So basically this entire

project into GitHub. So like you can see

this is the GitHub repo that I made for

the previous workflows and I had all of

them in one GitHub repo which is fine in

this case. If I go to the SRC trigger

you can see that we had the AI news

digest and the company research. So

here's what we're going to do. We're

going to push this project into GitHub

and then have GitHub sync with

trigger.dev and then they'll be able to

bring everything into production. And

now once again I just wanted to throw

out there this is why you have to make

sure that things are in aenv and that

you're not having any secrets in your

project because otherwise they'll be in

GitHub and I always make them private

either way but still it's just best

practice and then you're going to add of

course your API keys into trigger.dev.

So at this point what it's probably

going to do is it's probably going to

use your command line interface and it's

going to ask you to login with GitHub.

So once you get authenticated, it's

really easy and it can create repos and

it can, you know, make commits and it's

very very simple. So if you guys have

watched any of my videos where we've

built websites, then you know exactly

how this flow works. We're building code

in cloud code. We push that to GitHub

and then GitHub automatically syncs with

Forcell or in our case trigger.dev,

meaning that we have our actual live

automation or our live site

automatically syncing with GitHub. And

the reason why we want to use GitHub is

for version control. It keeps things,

you know, in the cloud and we can also

do more collaboration with other

engineers, other people, whatever it is.

So, I'd say getting familiar with GitHub

is probably a good idea. And just to

really hammer it home, you can see it

says good.v is excluded from our commit

to GitHub. Okay, awesome. So, we now

have our new GitHub repo right here.

It's called trigger- test. So, I'm going

to open that up. Make sure we are good.

Do we have our workflows? Yes, we do.

Right there. And now I'm going to go

back into trigger. I'm going to scroll

all the way down to project settings and

I'm going to connect a GitHub repo. I'm

going to sign up with my account and I'm

going to connect the repository that we

just made and hit connect. Now, right

here it says every push to the selected

tracking branch creates a deployment in

the corresponding environment. Which

means every time we have a new push to

the master branch in our GitHub repo, it

will automatically get synced into our

production environment. So, right now

we're in development. If I go to

production, we should see that it's

going to actually build up these things

now that I've connected our GitHub repo

because right here in GitHub, you can

see that we are in the master branch and

we have our TypeScript right here. Now,

if for some reason this isn't working or

you don't want to take the GitHub route,

you can always manually deploy this kind

of stuff and you can just tell Cloud

Code to look at this and it will help

you push this into the production

environment. Okay, so you can see that

those just got pushed through into

production. And unfortunately in live

production, this would actually only run

at 8 a.m. on Mondays. So we're going to

do a manual run right here. I'm going to

go in here. I'm going to hit test. And

I'm just going to go ahead and hit run

test. And so that's going to go ahead

and trigger this off. We're going to

watch this actually find those 25 leads.

Remember, it should automatically be not

loading any in if it's already processed

them before. So it's looking in Tampa,

Tulsa, Arlington. It found these leads.

And if I go to runs, it's also it should

be scheduling all of these for ClickUp,

which 7:29 p.m. It's doing that right

now. And if I go into our ClickUp, we

should see now that we have 50 leads in

here. And I just want to make sure that

none of these have been duplicated.

Okay. Actually, it looks like some of

these are. So, let me just show you guys

real quick what we might do about that.

So, I just did a test run of finding

leads, and it all worked. However, I did

notice that some of the leads were

duplicates. So, I thought that you had

worked on item potency here to make sure

that that didn't happen, but apparently

it was happening. So, can you fix this?

Okay, so it made a change in the create

leads workflow where it's basically

going to search ClickUp before creating

and now have a place ID. So, it says

that this change should be more

permanent, but it doesn't affect the

ones that already were made. So, I'm

going to go ahead and run this twice and

we'll see if there's any duplicates.

Okay, so I had to do a few more changes

and this really shows the importance of

using plan mode and having a really good

idea of what you want built before you

actually tell it to go build it. For the

sake of the video, I was trying to show

you how I could just kind of oneshot

prompt and and it would still be pretty

good. But this example showed really why

you need to plan harder because the

search criteria wasn't very big and it

had a weird way of dduplication. But now

we're at a much better spot where we now

have 48 rows and it shows that some of

them were filtered out because they were

duplicates and it was like searching

again and again until it was able to

fill up all the slots and now we have

more companies. So anyways, all of these

were being ran in our development

environment because we didn't want to

mess with anything in prod. And now what

we would do is we'd come back in here

and say, "Cool, this looks good. Push

this to GitHub." and then trigger would

automatically pull those live changes

from GitHub and we'd be all set for

Monday at 8 a.m. Okay, so hopefully by

now you guys feel confident in your

ability to hop into Cloud Code, go to my

free school community, grab these

resources, chuck them in there, and then

start building some automations that you

can then throw into trigger.dev to just

run all the time for you. If there's one

thing that I want you to take away from

this video, it's the fact that AI is

still very much a blackbox. These models

are insanely smart. you can see what

they do. But you also saw in this video

how I had to talk so much to it and I

had to like just be very clear. It's

just the whole idea of you no longer

having to write code, but you having to

be the person that assures the quality

and make sure that it's on track. But

anyways, I'm having so much fun learning

these new tools and diving into

different use cases. So, definitely let

me know in the comments what you guys

want to continue to see.

Cloud Code is now a 247 AI employee,

which means that it is always Cloud Code

O'. And that might be the nerdiest thing

I've ever said. Enthropic has finally

done it and launched scheduled tasks

natively for Claude Code, which means

every single process, every single

skill, everything you've been building

and using inside of Cloud Code just got

10 times more powerful. And they

literally could not be easier to set up.

So, in today's video, I'm going to show

you exactly how they work and tell you

everything important that you need to

know about them. Let's not waste any

time and get straight into it. So, here

I am in Cloud Code in the Claude desktop

app. Now, right now, you do need to be

using the desktop app in order to access

these scheduled tasks. Now, this

scheduled task feature came out about a

week or two ago in Claude Co-work. As

you can see, it's basically the exact

same thing. You could create scheduled

automations, but now they finally

brought it to Claude Code. And there's a

few ways that you can set them up. The

first way is you go over here to the

schedule tab, and you just click on it.

And you can see right here, run tasks on

a schedule or whenever you need them,

type/schedule, and any existing session

to set one up. So, those are the two

ways. You can either click right here,

new task. You can give it a name, a

description, give it a prompt. You can

choose the model you want it to run on.

You can choose the mode to run on and

you can also select the folder. And then

finally, you just say, "Hey, I want this

to run every hour, every day, every week

at this time." Boom. You now have a

scheduled automation. So that cron would

basically fire off. The session would

start up. And then the agent would read

the prompt. It would go through your

files. It would work in your project, do

whatever it needed to do, and then after

it's done, it would just stop. And the

huge unlock here, which is so exciting

to me, is that this isn't a

deterministic workflow. And so there's

some good there and there's some bad

there. But the good news is that you can

completely control it. And what I mean

by that is if you've been following some

other cloud code videos I've done in the

past, we build either like a Python

script or a TypeScript. And that is the

actual automation. And that is

deterministic logic code. Meaning that

will always happen step one, step two,

step three. If there's an error, it

can't fix itself. It just errors. And

then we get notified. But this isn't

just a Python script. This is cloud code

agent running the same exact way it runs

when you talk to it. And that's why this

is so exciting because Agentic workflows

are self-healing and they can read

everything in your entire project and

use all your tools. So, as you guys

know, you tell it to go do something and

it starts trying. If it runs into an

error, it doesn't just come back to you

and say, "Eh, I tried." It says, "Okay,

here's the error. Let me try three other

things." And then after I see which one

of those three other things worked best,

I'm going to update myself so that I

never run into that error again. So, now

you are no longer the bottleneck. And

these skills and these workflows can

actually get better and better over time

automatically. But the other important

thing to remember here is if you do want

it to be more deterministic and you want

more control, you can do that because

you could literally have it just execute

a script and that's the whole scheduled

task and it just is completely

deterministic that way. So how do you go

ahead and start creating some scheduled

tasks? Well, here you can see one I have

is called morning coffee. So I've showed

this one off before in a few other

videos, but basically every single

morning I would open up my cloud code

and I would say, "Hey, run morning

coffee." Which would help me plan my

day. It would look at my commitments. It

would look at the projects and help me

catch up on what the team's up to. But

now this can actually just run

automatically at 6:00 a.m. every

morning. And literally all that I did to

set this up was I said, "Take a look at

my morning coffee skill. I would like to

turn this into a scheduled task that

goes off every morning at 6:00 a.m. Help

me get this set up." It read the skill.

It complimented me on the skill. And

then it asked me one question about it.

And then a minute later, my skill that I

run every morning is now automated. And

if you've never used Cloud Code in the

desktop app, don't worry. It's super

easy. You can basically pull in, you

know, a GitHub repo or a different

folder and you can be working in the

exact same project that you're used to.

So right here in a new session I just

asked it what skills do you have in this

project and it came back and said hey

here are all the active skills we've got

content creation we've got research and

intelligence we've got visual diagrams

operations and meta and now any of these

skills I could just say okay cool turn

that into a weekly automation. All right

so there are a few limitations though

the first major gotcha is the fact that

your laptop has to be on or your

computer has to be on and the desktop

app has to be open. So if you turn off

your computer that automation will not

run. Now, the good news is, let's say

you had a task for 7 a.m. and you wake

up at 8:00, you turn on your computer.

Cloud Code would actually check back 7

days and see any scheduled tasks that it

missed and then would catch up and it

would run those. Obviously, that's not

perfect because some of those may be

timesensitive, but it is cool that it

has that ability. Now, what are some

other things to think about? Well, the

first one is that this thing is now

running without your supervision. And

ideally, it's not going to stop to ask

you questions because then what's the

point of having it automated? So that

means you want to be looking at your

permissions to make sure that it can't

actually go off the rails and do

anything like maybe make a major change

to your GitHub repository or go off and

delete things. And you can take care of

that by changing your local settings in

that project which you could just say,

"Hey, I want to make sure that you never

delete things. How can I put this in

your settings?" You know, deny a bash

command that does any deletes or

removes. And it will help you figure

that out. I've got a video coming about

this. I will tag that right up here once

that is live on YouTube. These are also

stateless. So basically, every time that

you run one of these, it's going to

throw it in a new session. So right

here, I did a test run of my morning

coffee. Here's the actual task itself.

And then when I open this up, I will be

able to see every run. And every run is

going to be fresh and it's not going to

have context of what happened on the

previous run. And the other thing, of

course, is that if you didn't put in an

API key or if there's literally

something that it can't do because it

needs your permission, it's going to

stop. So what I'd recommend is as soon

as you create a new task, just run it

manually and make sure that it can go

through all of the steps without

oversight. Otherwise, what's going to

happen is it's going to pause and it's

going to ask you for permissions to do

this and permissions to do that. Now,

sometimes it's a good thing that they're

stateless and that they don't have

shared memory, but sometimes you might

want them to, and that would be kind of

part of this whole self-improving thing.

So, here's how I imagine the

self-improving loop working. So, first

of all is fixing the actual script. So,

you can have in there the fact that if

it errors, edit your own code and make

sure you're fixed. The second layer is

the prompt. So, if you realize that

there's an opportunity to improve this

prompt, rewrite it and now you have a

new prompt. And then the third one is

potentially having a log for memory.

Whether that means every single run you

put some sort of like status of what

that run did or maybe you just have a

file that you overwrite so that every

time when the new agent wakes up, it can

look at the log and say, "Hey, this is

what the previous agent just did. Now I

need to run." So there's lots of ways

that you can kind of tweak these

scheduled tasks to fit your use cases

better. And once again, because they

have the context of everything in that

project, they're going to be super

powerful. They can look at any file that

you want them to. So that's what my

brain immediately went to. But I wanted

to see what Claude code thought. So I

asked it what it thought the most

optimal strategy was to make these

improve and make sure they have the

right context. So what it thought of was

a lean strategy where you have one file

per task. So basically every single time

the agent runs, it would overwrite this

file with information like here's the

last run, here's how long it lasted,

here's what happened, here's what I did,

here are known issues, and things like

that. And this is better than an append

log in some scenarios because like I

said earlier, if you run an automation a

thousand times, then you might have a

thousand append logs. But then what's

cool is the actual structure of your

prompt. So when you're creating a new um

task right here, the way that you prompt

it, you could basically say, okay,

before you actually do your job, go

ahead and read this file, which is

basically the last run, and then you do

your main task. And then after you're

done with the task, overwrite that file

with any current issues or status or

anything that you found that might help

the next agent. So, obviously I'm going

to be playing around with different

structures of having context shared

between these different, you know,

tasks, but that's just something that I

thought would be really, really cool.

So, another thing I wanted to talk about

is because this is in the desktop app

and because this is running on a

schedule, how do you want to get

notified that that scheduled task has

been done? So, the desktop app does have

notifications, but they're not super

great. At least it wasn't making any

noise and it wasn't capturing my

attention. It's cool that everything

gets organized over here. So, as you

have more tasks, you can see them all

and it's organized. But what you can do

is you can add a hook. so that every

time you actually get a sound. So what I

did is I set up a hook so that every

time a cloud code session finishes I get

a notification. So listen to this.

So that was like kind of the default

Windows little sound. You can change

that. But that's really helpful because

I could be working and I could forget

that a scheduled task might go off and

then I get that noise. But the other

thing I would recommend is in the prompt

of the actual skill itself, maybe just

at the bottom say, "Hey, once this is

done, just shoot me a ClickUp message

and say that this happened." And that's

probably what I'm going to set up for

all my scheduled tasks. And if you're

curious about setting up hooks,

literally just say to cloud code, set up

a hook. I want you to play a sound every

time you finish talking to me and it

will do it in like a minute. And the

last thing I was curious about is the

fact that we're limited to the desktop

app. Now, Enthropic is shipping like

crazy. So, I'm sure in a week or two

that this is going to be open in the

terminal and in the IDE extensions and

stuff like that, too. But for the

moment, it's only desktop app. And

basically why is because all of the

actual like cron logic and that kind of

metadata lives in the desktop app even

though the actual files live in your

computer. They live somewhere where

terminal or your VS code cloud code

could actually see it. So I was

interested in that and I said are you

able to see my scheduled task for

morning coffee? It runs at 609 and

here's where it lives because it lives

kind of in this global folder path right

here and it can see it right because it

just exists as a file. But what it can't

do is it can't create new scheduled

tasks because it can't actually touch

the cron that the desktop app of cloud

code sets up. But what it could do is it

could edit it. So it could improve it.

It could make changes, but it can't

create them or like run them. Now that's

actually not a huge deal to me right now

because I usually work in VS Code, but I

can just have the desktop app open and I

can just leave it open in the background

while I've got my computer on and all of

my scheduled tasks will still be

running. And so now that Cloud Code is

so powerful on its own, it can actually

like do things in the browser as well. I

truly think we're getting to that point

where you can automate anything.

Cloud Code can now remind you to do

things, check on things proactively for

you, and work for days straight without

you ever touching it or needing to give

any input. So here you can see I just

said, "Remind me at 10:23 a.m. to check

on my project." It goes ahead and uses a

cron create tool to set this reminder.

There we go. 10:23 just hit. I didn't

touch it. and it just said, "Hey, Nate,

this is the reminder to check on your

project." So, just shot off this one

that says, "Every 10 minutes, check my

ClickUp to see if there's any new

developments on our project." It's using

the loop skill, as you can see, which is

a new built-in skill, and it creates a

cron for every single 10 minutes. And

now, this would run for the next 3 days,

every 10 minutes until I told it not to.

And this doesn't have to be every 10

minutes. It could be every hour. It

could be every 5 minutes. It could be

whatever interval that you want. And

this is all thanks to the newly released

feature or skill loop, which is a

powerful new way to schedule recurring

tasks for up to 3 days at a time. And

this is so funny because less than 12

hours before this was announced, the

scheduled tasks in Cloud Code was also

announced. So, right off the bat, those

two features might seem like they're the

exact same thing, but they're actually

super different in how they work, and

they have different use cases. So, in

today's video, I'm going to break all of

that down and tell you everything that

you need to know about it. And by the

way, if you haven't watched my new

scheduled tasks video, then check that

out right up here, and then hop back

over to this one. All right, so as you

guys just saw in the quick demo, we now

have the ability to use loops, which

means that we could say something like

/loop every 5 minutes, check on the

deploy, or we could just say that in

natural language, which is awesome

because it invokes the loop skill and

then it creates that cron job right here

in cloud code. And you'll notice that

this is in my VS code. So this is

available in your terminal, in cloud

code desktop app, in VS Code extensions,

wherever. This is just a core part of

cloud code now. So if you're not seeing

this, just make sure you update your

extension or you update Cloud Code. And

this lets you set up loop intervals or

reminders. So reminders, like you saw

that first demo, I just said, "Hey, at

this time just tell me this." And in

that session, it will bump up a message

without you triggering it. Or you could

have them be intervals. So you could say

every 2 hours. You could say every 30

minutes. Whatever you want that actual

interval to be. And what's cool about it

is it does it all in the same session.

So if I leave this session up every 10

minutes, it would check everything right

here, which means that it's able to

continuously read through what happened

in the past one, and it continuously

sees what we're doing. Now, obviously

there are some pros and cons there, but

just wanted to point that out. The major

con there being your context, making

sure that if something does go off every

10 minutes, you're not going to get a

huge report and then every 10 minutes

you just more tokens, more tokens, and

then context rot. It's basically

scheduling a prompt that you would be

sending in here and then firing off,

which means you can loop skills. So, if

you want every 20 minutes, for example,

run a skill called review PR, you could

tell it to every 20 minutes run the

skill. It would run it, it would wait 20

minutes, and then it would do it again.

And of course, you could use actual

slash commands to invoke both the loop

and the skill. Or you could just say,

"Every 20 minutes, run my review PR

skill." And of course, the onetime

reminder feature. So at 3 p.m. or in 45

minutes, remind me to do this or check

in on that. And Claude will basically

pin that time. It'll create that cron

and then once it's done, it'll just

delete itself. So whether that's, hey,

at 4:30, remind me I have to go do this

or every hour remind me to just stand up

and like look away from my screen for 5

minutes, it can do that. All right. All

right. So, there's a couple things that

I wanted you guys to understand about

how this actually works. So, let's just

play around a little bit. Hey, at 10:40

a.m., can you please remind me to take

out the garbage? Cool. So, what that's

going to do is it's going to use the

cronreate tool, and it's going to create

that basically schedule to remind me

take out the garbage. And what you can

see here is the actual prompt. So, at

this interval, which is just how cron

works, it's basically going to shoot a

prompt into this window that says remind

Nate to take out the garbage. You can

see the recurring equals false. Now, of

course, the key is if the session is

closed, then that cron is going to

automatically be killed. So, now

something interesting. I'm going to open

up a new session and I'm going to say,

"Hey, every hour, can you just remind me

I need to stretch my neck?" And I'm

going to shoot this one off. And we'll

see how this one is a little bit

different because this once again

creates a cron. We have a prompt. And

you can see in this one, we don't have

the recurring equals false. We just know

that this cron is going to go every

hour. But these loop jobs or task jobs

are per session. So these two tabs are

two different sessions. So if I came

into this session and said, "Can you

please tell me all of the scheduled loop

tasks that we have today? It's going to

use a tool called cron list, and it only

can see the 10:40 a.m. take out the

garbage. It cannot see the task that

exists in this session because they're

independent and they're separate. Now,

one interesting thing to notice is that

this session didn't actually invoke the

loop tool. The loop tool basically tells

it how to set up cron jobs and how to

use the cron create. So if you don't see

loop, don't worry. It's still actually

doing this in a loop. It's just kind of

about the actual wording. So, if I was

to open a new one, let's see if I

actually call the loop tool right here.

So, I do loop and then I just say, you

know, um, check my ClickUp. This one is

going to default, I believe, to 10

minutes if you don't specify a time. And

it might invoke the loop skill because

we actually called it to, but looks like

it didn't because it knows exactly what

it needs to do already. So, the point

being, all it matters is that the cron

is being created. It doesn't always

matter if it invokes the loop skill or

not. And then if you wanted to cancel

one of these jobs, all you'd have to do

is either close out of the terminal or

just say, "Actually, I don't need this

anymore. Go ahead and cancel it." And

that one invokes a different cron skill

called cron delete. It shoots over the

job ID. And now that it's canceled. And

one final thing to keep in mind is in VS

Code, if you close out of a tab and then

you just open up that conversation

again, that still will kill those crons.

So you guys just saw how pretty much all

of this worked. We have cron create to

schedule. We have cron list to list

them. And then we have cron delete to

cancel them. And all of those can be

invoked with natural language, which is

awesome. So now let's get into some of

the limitations and then I'm going to

compare them to the actual scheduled

tasks feature. So the first big one is

that we have a 3-day loop expiry, which

is just basically for safety. It auto

cleans things up if you forgot you had

all of these loops running. So once you

create a loop, it basically has a 3-day

timer on it. It can run for day one, it

can run on day two, and then on day

three, it can run up until that last

fire, and then it will autodee. And if

you want anything longer than 3 days,

then you would either just recreate that

loop or that probably indicates that you

should just turn this into a legitimate

scheduled task. Now, the other thing

that you can do is if you want to

completely disable scheduling, so maybe

in your natural prompting it's

accidentally creating all these crrons,

you could go into your environment

variables and just disable that and it

would probably be able to help you

figure that out. So the other things

here are that if you close the terminal,

your tasks are gone. It doesn't have

catchup. So the scheduled tasks, if you,

you know, opened up your desktop app and

you missed a bunch, it would catch up

automatically. This doesn't do that. And

there's no persistence, meaning after

your 3 days and you wanted to do that

same loop again. It would be a fresh

session. But obviously, there's tons of

things you can do here with context

management and reading different files

in order to kind of Frankenstein your

own fix there. So now that all the

features have been explained and you've

seen a demo, I think that probably you

understand the difference between the

loop and the schedule tasks a bit better

now. But let's just go over some of the

key highlights. The loop has your 3-day

expiry. It's all done within one session

and there's no catch-up. It's basically

a help me now or help me on this project

for today type of function. The schedule

tasks are dis stored. They're longived.

They have catchup and these are like

daily, weekly, monthly functions that

can run indefinitely. Of course, with

both of these though, the terminal or

you know the app has to be open and this

one is only currently available in the

desktop app. But I can imagine with how

fast Enthropic is shipping things, maybe

by the time you watch this video,

scheduled tasks are already out for the

terminal and extensions as well, the way

that loop is available in cloud code

everywhere. So basically, it's one

simple question. Do you need help right

now on a project or do you need help

with something every day or every week?

And that's how you decide if you use the

new loop feature or if you use scheduled

tasks. So I thought I'd end off real

quick by giving a few maybe practical

ways that you could actually use loop

rather than something scheduled. So

maybe all day you're waiting on a very

urgent email. Just set up Cloud Code to

check in on that email every 5 minutes

and if it's there, it can automatically

let you know. Maybe you're working on a

deploy and you want to just pull that

and check every, you know, hour or so if

everything's working okay. Maybe you've

got a deadline due at the end of the

week and you need a 3-day sprint to be

constantly checking in on the team and

checking in on progress. Maybe you're

testing and iterating. Maybe you're

watching logs. Maybe you're tracking

changes. There's so many different use

cases here. There's so many different

ways to use the loop to prompt an agent

to have different files, to use

different skills, and it's really,

really cool the way that you could

potentially set these things up. Now

that we've built our first couple

workflows, we understand the components.

Cloud code is insanely smart. We use it

in plan mode, and it helps us build

automations. And then we take those

code-based automations and we put them

in something like modal or trigger.dev,

and they run 24/7. We understand

workflows, we understand tools, and we

understand claw.md. But now, we're going

to get a little bit more advanced. So,

we're going to dive a little bit deeper

into some best practices around your

claw.md. We're also going to discuss

project architecture and some other

helpful built-in commands. So, let's get

into it.

Okay, unfortunately, we're back to the

boring slides, but need you guys to pay

attention here. So, more concepts. This

one's going to be short. We're going to

talk about more claw.mmd tips. We're

going to talk about essential/comands,

and we're going to talk about project

folder architecture. This one is really

important to pay attention to. This is

probably one of the things that caused

me the most confusion when I first

started. So, we're going to make it

clear.

So, you've seen the cloudm a good one we

know contains a project overview, text

stack, architecture overview, coding

conventions, common commands,

constraints, and where it can find more

context.

Now, let's talk about some best

practices.

You might see different things online. I

like to try to keep mine under 200

lines. And I found that by effectively

using, you know, routing rules just

basically means pointing to different

files and using um other compression

techniques,

keeping it under 200 100 lines is doable

and it's great. So shorter equals less

tokens. Be very specific. So saying

something like use two space annotation

is much better than just saying format

it nicely. Treat this as a living

document. So just because you made your

cloudd file does not mean you're done. I

update my cloud.MD MD file probably

every single day if not yeah probably

every single day I was going to say

every hour but that would be a hyperbole

every single day I'm updating my clawmd

now you can also use in it we talked

about that and you can also use rules

for putting certain things in which

means let's say you have a specific rule

about the way that you like to write

emails or the way that you like to

handle internal comms there's no point

to put that into the claude MD because

does claude need to know that every

single time you talk to it. No, it needs

it on occasion. And so what you can say

is, hey, when you need to understand

rules about the way I speak, go to the

rules folder and you can find the rules

there. Right? So that's a little trick

we call routing. So it's really

important to understand how you can

route as much as possible. The cloudmd

is not a know all

file. It is a I know where everything I

need to find lives file. It's basically

your table of contents. Think of it like

that.

So

no. Okay. I I thought I had another

thought, but we're going to move on. So

this is the example I showed you guys

earlier, right? So this is my executive

assistant. This is the beginning of the

cloud.MD. And you can see this is an

example of routing right here, right?

Because if I jammed everything about me

in this file, everything about my work

or about my team or about my current

priorities in this file, it'd be huge.

But I can say, hey, if you need any of

this stuff, you know where to find it.

And it's really, really effective.

So

you're in VS Code, you're in cloud code

and you have folders on the lefth hand

side, right? Like maybe you've got your

workflows folder or maybe you've got

your, you know, brand assets, whatever

it is. What you want to do is you want

to make sure your projects have a folder

called

dotcloud is basically like that project

directory, the project settings. And

there's a couple different types of

dotcloud. Now, for now, I'm not going to

touch too much on the system level path

because this is usually if you're set,

you know, within an organization, but me

locally working with my team and stuff,

I either have a global cloud folder,

which is not the one you see in VS Code,

that lives somewhere in your home

directory on your computer, or you have

your project cla

that you're looking at in VS Code. So,

this is local. This is based on your

project. This one is based on every

cloud code project you ever work on

ever. So, for example, let's say you

have a setting in your in in your um

cloud code, right? So, I don't want to

get too ahead of myself here, but

um I've got basically a setting that

always allows a certain MCP server,

right? Or a certain front-end skill,

let's just call it that. Now, if I'm

using that same configuration, if every

single project that I want to work on

ever, I want to allow that same server,

then it would make no sense for me to

put it in every single project when I

could just put it globally. Okay, so

that's just kind of the the idea.

There's a difference between global and

project level.

So,

we have automemory, which means that we

have cloud.mmd, which Claude always

looks at, but Claude also has auto

memory, so things get persisted across

sessions, which is really, really cool.

So if you tell Claude always use, you

know, PNPM, not npm, claude will save

that to a global claude folder, and you

know it's global because you have this

little tilda in front of it, right? So

back over here, you can see this was

just a dot /.claude, but this global one

is a tilda. So whenever you see the

tilda, it's a global setting. So now

this memory.mmd file that's global

across every project, Claude is able to

look at. And you can also edit that

automemory file anytime. So the same way

in chatbt on the browser or in claude on

the browser you have persistent memory

it's basically the same thing. So it's

really cool.

Now here are a few slash commands to be

aware of for session management. So we

obviously talked about slashinit. We've

talked about slashclear. It wipes the

conversation. We've talked about slash

compact a little bit but what's cool

about slash compact. So like let's say

you're at 60% context window. Usually at

60 I like to compact. Now, you can just

do compact and it will say, "Okay,

here's the conversation. Here are the

five most important things. I'm going to

pull those out, get rid of everything

else, and put those five most important

things back in the conversation." So,

now we are back at like maybe 10% of the

context, and we still have all of the

important stuff we need.

Now, what you can do is instead of just

saying /compact, you can say /compact

keep the information about the website

design, and it can get rid of everything

else. So, you can be specific about what

it compacts, which is pretty cool. We

have slashre, which honestly I don't use

that much, but it's nice that it's

there. It's basically an undo button.

And then we have /resume, which means

you could resume a session that you were

working on, you know, a couple days ago

or a couple weeks ago.

We have information and diagnostics

commands. So, we've got /context we've

talked about. We've got /cost, which

shows the token usage and cost. We have

slashmodel to change model. We have

slashhelp to look at all the commands.

We have /d doctor which can run

diagnostics to see your installation and

see if everything's working. And we have

slash status which will show you the

version of cloud code and your model and

your account and things like that. Now

the cool thing about this is you don't

have to memorize these. You can

literally say hey I want to look at

this. Do you have any commands? Or hey I

want to do this and it might just invoke

them automatically. But just kind of

good to know right.

So configuration we've got our SL

mememory which I talked about to auto

auto or to edit that automemory. We have

slashconfig. We have SL permissions, we

have SLMCP, and we have SL aents. All of

these are going to get touched on later

in the course as well. So you don't have

to memorize these. Once again, just

trying to get you familiar.

So once again, we have the project

folder architecture idea because this

goes beyond just our cloud MD. This goes

into skills, agents, MCP servers,

settings, everything. So we have once

again user level, global, we have the

tilda, and this is across all projects.

We have project level settings which is

in yourcloud you have a settings.json

which means anyone that accesses this

project can see that setting file and

configure it or we have our local

project which is settings.local.json

and that is just you. Okay.

So what goes where settings.json it goes

in your personal defaults claude

settings.json goes in your team

standards and yourcloud/s settings.local

local is basically the overrides for the

specific project. So it goes in this

order. Let's say you want to do

something or you want cloud code to do

something. It will first check your

local settings

and then it will check your project

settings and then it will check your

global. So this is basically the

hierarchy. So like let's say there's a

certain command called read, right? So

let's say it wants to read a file. If

local says do not ever use read, it will

instantly stop. But if um local says yes

you can and project says yes you can and

then global says no you can't it'll stop

there. So that's just kind of like the

order of operations the hierarchy.

So this is what it looks like. This is a

project level directory. So let's say

you open up VS Code and you have a

project called um websites. That's what

you'll see up top. Then below that

you'll see your cloud. And when you open

up yourcloud, that's when you might see

your settings.json, your

settings.local.json,

your cloud.md, your rules, your skills,

your agents, your commands. Oops. And

then outside of that folder, you might

see your MCP config or you might see

your cloud. Mmd. And so those are just

kind of like the different drill downs

that you'll be able to see.

Now, this one is a global one. So it

looks very similar, right? We've got

cloud, we've got settings, claude,

agent, skills, rules, whatever. But this

is the global one. So this doesn't exist

in a particular project. It exists on

your cloud code configuration.

So what is the purpose of all this?

Don't want to hammer this home, but I

thought that this little, you know, I

don't want to over beat a dead horse

here, but this is a breakdown to look at

as far as like the file, the purpose,

and if it's shared or not. So hopefully

this is all

at a high level making sense. I

understand though looking at this it

might look completely foreign and you're

like what in the world? I promise you

that's normal. All you have to do is get

into there and start building and all of

these videos are going to walk you

through it and it will start to make

more sense. It's just so much more

helpful to understand what you're

looking at first. At least in my

opinion. Okay. So the dotclaw directory.

What is getit ignore? because you're

probably going to see that when you run

/init or when you start to have, you

know, projects being synced to GitHub.

You're going to see something called.git

ignore. This is basically just a system

that tracks your codebase changes,

right? And ignore is literally just a

file that tells cloud code, don't ever

push any of the files in here to GitHub.

So in your dockit ignore, maybe you have

some pictures of yourself that you don't

want to get out there, or maybe you have

some passwords or API keys. All you'd

have to do is in the docket ignore just

put the name of those folders or files

and then they'll automatically be

excluded from GitHub or from git.

Um

that's basically it, right? There's also

going to be one called.git keep. So same

thing.

So here is an example of my executive

assistant project, right? You can see

that we've got some stuff going on here.

We've got the cloud folder. We've got

archives brand assets. We've got

projects which is currently open. And

you can see that there's a lot of

folders and a lot of files in here.

You'll also see down here that I have a

claw.md. I also have a claw.local.md.

I have agit ignore. And then you also

see that some things are grayed out like

the env or the Google ooth json.

Now anything that exists in the ignore

will be grayed out. And that's just a

visual way of saying this is not going

to be put in GitHub, which is great.

Anything that is green is a new file

that git has never seen before and it

hasn't been committed anywhere. So I

love this because it's visual. I can

instantly see, oh, do I need to make a

push? Do I need to save my work?

Essentially, anything that's yellow

means that it's a existing file in git,

but there was some sort of update. So

you have to make a new commit. And

that's really nice because as everything

gets more yellow and gets more green,

push it to GitHub, it'll all go white.

And then you know you're good.

So,

that is a lot more of the foundational

concepts that you really need to know.

We're going to get back into building.

We're going to do some more stuff here.

But hopefully this session was helpful.

But I'll see you guys over there.

Now, we're going to jump into a quick

segment about Rag. And in this case,

we're using Google's new embeddings

model that just came out. And it's

really cool because it lets us really

easily embed videos, images, and audio

as well as our text. So, like I said, it

just makes it super super easy. So,

check this out.

Google just dropped Gemini Embedding 2,

which is their very first natively

multimodal embedding model, and it is

already blowing my mind. This means that

you can have completely multimodal

databases with text, images, videos,

audio, and documents. And it can

actually understand the nuanced

relationships between these different

types of media so that you can have

actual realworld answers back. And

here's a quick look at some of the

benchmarks, which I always think are

important to look at, but I think it's

always worth taking it with a grain of

salt. And that's why in today's video,

I'm going to show you a few examples

that I already built out that are super

practical. And then I'm going to show

you exactly how you can set this up for

yourself. And trust me, it is so much

easier than you probably think. So, let

me show you some examples and then I'll

teach you how to do this yourself. So,

right here, you can see that I've got a

project called manual, which basically

stands for like instruction manual. So,

what I did is I dropped in this PDF

right here, which is a 68page PDF about

how to use this vacuum cleaner. You can

see that it's pretty complex. It's got

tons of different text. It's got tons of

diagrams. It's got images. And if you

wanted to be able to chat with it, it

would be pretty complicated to build

this ingestion pipeline if you use

something like Nitn because you'd have

to figure out exactly how you want to

chunk it and how to capture the images

and how to store those and how to pull

them back. But I kid you not, I dropped

in the PDF right here and I said, "Hey,

Cloud Code, there's the PDF. I want to

be able to chat with this using Google's

new embeddings model. Just go build it

for me." And not only did it build it

for me, but it built this app where I

can actually talk to it. So let's say I

ask you know how do I clean the filter?

It's searching right now our Pine Cone

database and in the database we're

storing both text and images. So here

you can see it says to clean the filter

follow these steps number one number two

blah blah blah. And then down here we

have actual images. So if I click on

this one we can see the actual diagram

that it pulled from because sometimes

when you're trying to troubleshoot

things especially if it's physical an

image is way more valuable than text.

And what you can see here is that it

also returned the same diagram in

different languages but you could turn

that off if you didn't want to. And

what's super cool is at the end I can

actually expand the sources and it shows

me the different pages that it looked at

and the confidence score or the percent

match that it had for that page. Let's

go ahead and try one more for this demo

which is just a very broad what are the

parts and I'm assuming there's lots of

different pages that it might need to

figure out what the parts are. So what

we got here are we have the main

components from page six. We have what's

included on page seven and then we have

available accessories. So that's super

good. And it looks like we got three

different images. So we have what's in

the box. We have the actual getting to

know your Hoover Impulse cordless

vacuum. So, all the other different kind

of components here. And then the final

image is how to order extra accessories.

So, that's just super cool. Okay, so

that was our instruction manual example.

I dropped in one PDF and it basically

was able to turn that into text and

images in our database and pull

everything back accurately. So, then

let's scale it up a little bit. I am

doing a roofing example. So, in this

one, I gave it 13 images and all these

images are different roofs that might

have some sort of issue. So, let's say

you're a roofing company and you help

fix roofs. What might be helpful is if

you had an app where you internally or a

client could upload a picture of their

roof and you could get like a quote or

an internal brief about any past work

that you've done on a roof that looks

like that. So, if I drag in a picture

right here, it shoots it off and says,

"Find similar past projects for this

roof." It's searching the database. It's

looking through all of our different

past projects, and all of those images

have metadata like how much this costed

us or, you know, how long it took, how

many team members. So, here are the five

similar projects. We get a percent match

for each of them as you can see. And

then we get a description like quote

range and averages, team size, trend,

roof types, breakdown. And so,

obviously, I'm not a roofing expert. If

you had some subject matter expertise

about roofs that you could add into

here, this would obviously be better,

and you would have your own data. But,

it's just really cool that you can get a

quick search across potentially hundreds

and hundreds of projects to do this. And

I could ask a follow-up. So, let's say I

said, "Okay, awesome. Can you tell me

about the one that we did in Richmond,

Virginia? It looks pretty similar. And

at this point, it could pull the

metadata from this image and it could go

grab other pictures from that file if we

had them. But anyways, we get the basic

info, the scope, what stands out,

pricing, context. Super super awesome.

But yeah, clearly this needs some

subject matter expertise. It obviously

made up all this data because I feel

like this roof would have costed more to

fix than this roof. So, so if you've

never built a pipeline like this before,

then it might not seem super impressive

because that type of functionality is

pretty standard on a lot of chatbot

based features. But the fact that I

built both of those demos in less than

30 minutes is what truly blows my mind

because that would have taken me several

hours, if not several days, to build out

an NAN. And that's why I had to show you

guys this stuff. All right, so we're

going to hop into the live build. But

real quick, in case you haven't really

heard of like Rag or why this multimodal

stuff is awesome, let me explain it real

quick. So rag stands for retrieval

augmented generation and it basically is

just the concept of your AI agent only

knows so much in its training data. So

if you ask it a question and it doesn't

have that information, it has to go grab

it in order to generate a better answer.

So it basically retrieves information,

it augments its answer because it has

more data and then it generates an

answer or generates a response to you.

Now typically when we think of rag and

we think of a vector database type of

rag, we have to look at it like this. We

have some sort of data source, right?

whether that's document or video or an

image. And what happens is we have to

turn this document into vector points or

little chunks. So for example, if this

was a document about our company, then

maybe we'd split it up into three

chunks. Those chunks would run through

an embeddings model, which is, you know,

Google's new embeddings model 2 that

we're talking about today. And then it

would spit out these vector points,

which would basically just be a

numerical representation of what the

data means. So this chunk might be

placed over here because it's company

overview information. This chunk might

be placed over here with financial

information. And this chunk might be

placed over here with marketing

information. And just to help you guys

contextualize that, when I was first

testing this out, I did a demo where I

dropped in an Adam Sandler and me

picture that was Nano Banana. Um, a

random picture of me, a video of me

using Claude Code, a video of a dog

playing guitar, a video of me speaking,

um, a couple text files, and a couple

more images that were just literally so

random. I put a picture of smiley face

potato fries in here. And what happened

after it embedded all of those is it

gave me this report which is basically

the multimodal embeddings but this is a

2D view rather than a 3D view. But you

can see that it's placing things where

it deems appropriate. So up here we have

you know first aentic workflow which is

in the category tech and it is a text

file. We've got over here a dog playing

guitar which is in the category

entertainment and the modality is video.

We've got the smiley face rise which is

category food. The modality is image. So

I think you guys understand the point.

We have a source of truth that gets

embedded and then it gets placed

somewhere in a multi-dimensional space

based on the actual meaning or you know

value of what that source of truth is.

And so that's why it's so cool that we

can have a space where we have images,

videos, audio, text, documents all in

the exact same space and the AI is

intelligent enough to query through it

to find what it needs in the right

context and when. And this is obviously

a bizarre example because smiley face

fries and a dog playing guitar and a

video of me talking have nothing to do

with each other. But if all of these

were pictures of roofs, for example,

then they would be very split up based

on like is this water damage or is this

just like old age or you know other

things about roofs. So if you've never

used cloud code before or you want to

follow along with this video exactly, I

use it in Visual Studio Code which is

free to download. And when you download

that, it'll look like this. All you have

to do is open it up, go over here to the

extensions, type in Cloud Code, install

this, and then sign in with your account

in order to get connected. You do have

to be on a paid account. You cannot use

free cloud code. And then what you're

going to do is click on this in the top

left to open up a new folder which is

basically just the project that we're

going to work in. And I'm going to open

up a brand new one. So my screen will

look exactly like your guys' screen and

you can just follow what I do. Okay. So

I just opened up a folder called

embedding demo. I have this stuff over

here. I'm going to exit out of. I'm

going to click on this orange button

which opens up cloud code. And now your

screen should look like this. So I'm

going to show you exactly how I got

everything set up. I went ahead and I

switched to plan mode. I went over to

this documentation from Google and I

went to the actual like API embeddings

information. I copied this URL, pasted

it in and said, "Hey, Cloud Code, I want

to use Gemini's new embeddings 2 model

in order to have a Pine Cone vector

database filled with videos and images

and text. Can you please build me a plan

to set all of this up? create me av file

with the placeholders and I will drop in

my pine cone API key, my Gemini API key,

and my open router API key. So, the Pine

Cone API key is so we can set up the

database. That's actually going to look

like this. Just go to pine cone.io. And

you can see in here we've got our

different databases for our manual

multimodal for our roofing projects. And

then this was just a random one. And the

cool thing is all you have to do is give

cloud code your API key. It will build

the database and it will throw

everything in there. You don't have to

do anything. So on Pine Cone, you can go

ahead and use the starter plan, which is

free. And this will be more than enough

to just get started to see how it works.

And then you're going to go over to

Google AI Studio. You're going to come

over here to get API key and then create

a new API key right here. And that's

going to be for accessing Gemini's new

embeddings model. And then you're going

to go to Open Router.ai. If you wanted

to, you could use an OpenAI key or

Enthropic key. But Open Router basically

just lets you have all of these models

in one, which is why I like to use it.

So once you get an account in here,

you'll basically just go to your

account. you will come to your API keys,

create a new one, and then give that to

Cloud Code. So those are the three

things we need. So what it does now is

it spits out this plan. So we can

basically read what Cloud Code is

planning on doing. Here's the context.

Here's the proposed project structure

that it's going to create. Here are the

dependencies. And here is the basically

step-by-step plan. Now, if you wanted to

change anything, you could highlight it,

you could add comments, and you can make

suggestions. For the sake of the demo,

I'm just going to go ahead and auto

accept what Claude is thinking to do.

And hopefully it gets everything built

out for us. And then all we have to do

is give it the documents that we want to

embed. So here's the to-do list. I'm

just going to check in with you guys

once this has finished up. Okay, so you

can see it built all those files. And

now in ourv it gave us these

placeholders. So this is where you would

go grab Gemini, paste it here. Go grab

Pine Cone, paste it here. And then after

you paste all three, just make sure you

save this file before you exit out of

it. All right, so I added those keys and

now I said where should I add my images,

videos, and text? And it wants me to put

them into the data folder. So, I could

open this up and make subfolders for

image, videos, and documents. But what

I'm going to do is I'm just going to

drop everything in there, and I'm not

going to tell it which is which.

Obviously, it will be able to figure it

out. So, I'm sorry for being boring, but

I am going to use the same nine files

that I used for for the earlier demo

just because it's a good mix of, like I

said, images, videos, text, and we're

going to shoot this off now. All right.

So, normally I would say this in plan

mode, but I'm just going to keep sending

it. Right now, I said media has been

dropped in, as you can see over here.

Get that into Pine Cone. then build me a

simple chat web app on a local host so I

can test that everything works well. I

want you to use sonnet for the chat

model. So these are the three pine cone

indexes that we currently have and like

I said it's going to go ahead and build

us a new one because it has our API key

now. Okay, so right now it just created

that pine cone index and now it's doing

the ingesting which like I said this is

my favorite part because cloud code is

so so powerful being able to do this and

then the new model the new embeddings

model is also so powerful. So combining

them together makes this so seamless

where you can build a database with

natural language because like I said,

I've built multimodal vector store

agents before in NN, but it's so

complicated. They're super fragile and

there's a lot of hoops that you have to

jump through in order to just store

these different buckets and have all

these descriptions of the images. This

is so much better. And there's one thing

I noticed is that it says to build the

chat web app with Sonnet. So once it's

done ingesting, I'm going to stop it and

correct it. So, if you ever notice that

it's doing something wrong, there's

nothing wrong with stopping it and

sending a new message because it still

understands the context. So, now I'm

going to go ahead and stop this. I'm

going to say, "Hey, so I don't want you

to build the chat web app with Sonnet. I

want you to still use Opus. I just meant

on the web app when we're actually

talking with the AI, I want that AI

model to be Sonnet." So, make sure you

use the front-end design skill to build

this chat web app. Just keep it super

simple. Okay. Now, I'll check in with

you guys when we have our PC. Okay. So,

looks like our chat app is ready. I'm

going to click on this logo host and we

have multimodal rag chat. So now I can

ask a question. Okay, so I'm just

shooting this off to see what happens. I

said, "How should I be looking to get

workflow clients and do you have any

interesting pictures of people meeting

each other? Potentially warm

connections." So I wanted to see if it

can pull the workflow clients text,

which it probably will, but I wanted to

see what it did here with the picture of

me and AI Adam Sandler. Okay, so it came

back and has some some methods which

came straight from my text document, but

it says that it doesn't have any

pictures of this exact thing. So, what

I'm going to do is I'm just going to

copy this actual string. And I'm going

to go back into cloud code and say,

"Awesome. It's working. Here is a

conversation I just had with it." And

then I'm going to paste in that

conversation I just had. I want to

understand the way that it thinks about

the images or videos in the database so

that I could ask a question that would

get it to invoke and send me the image

or video. And this is really the mindset

shift when I work with Claude Code. It's

just about being genuinely curious. If

you don't understand something, just

ask. So here it says right now the

system can't actually show you images or

videos. It only stores a text

description alongside each embedding.

Here's how it works. Images just the

description I wrote during ingestion.

Videos, same thing. It's just the

description. So what you can do from

here is you can have better descriptions

to go along with all your pictures and

videos which you kind of saw earlier in

the demo where all of them had some

metadata. And then what we can do is

actually serve the media. So we can

update the chat app to display images

and videos inline when they come back so

that you're not just getting a file

name. Thanks for explaining that. I'm

just doing a quick demo right now for

YouTube. So, what I want you to do is

just add some metadata about the dog

playing guitar video, just saying that

it is a cartoon golden retriever, I

think, playing the guitar in front of a

fireplace. And update the actual app so

that it can serve us that media. And I

just want to validate that this works

and it's able to search through

different types of media. So, as you can

see now, what it's going to do is it has

to reingest the video for better

description and update the app. And I

don't think by default it's going to do

this, which is why I would say to use

plan mode. But in this case, you might

have two duplicate videos in the

database. And you would want to make

sure that it's deleting the old ones or

it's basically just upserting this new

one. So now if I say, "Show me the

golden retriever playing guitar," it can

actually pull that back. And right here

in our app,

we can watch the video. So this is just

so so cool. You could have a database of

tons of different videos and you could

be able to actually search through them

with rag. Now, the one limitation of

that right now is that the videos are up

to 120 seconds and only MP4 orov. The

images are capable of processing up to

six per request supporting PNG and JPEG

formats. And I imagine that this stuff

is going to get a lot better. You can

even see that it was able to get over

this limitation because the document

that I gave it was like 68 pages long.

It just had to figure out how it could

break that up, chunk it up, and still

maintain context. And I didn't try with

audio yet, but that would be very

similar to the way you do your videos

and images. The key thing about the

audio is being able to give it good

descriptions so that the AI understands

what's actually in that audio file. So

that's where the subject matter

expertise of the systems that you're

building really, really does matter. The

importance and value is way more

shifting towards being able to

communicate clearly, having

understanding of processes, deep

understanding of processes and where

holes might be and where you need to be

very explicit rather than just knowing

technically how to configure different

nodes and how to formulate a JSON body

for an HTTP request.

All right, so we've been working a lot

with workflows and automations and data

and Python scripts and you know stuff

like that. Let us get a little more

creative now. We're going to jump into a

section about learning how to build

really nicel lookinging websites and

actually being able to deploy those

websites on a real domain. So let's get

into it.

All right, so a lot of us have been

building editin workflows for a while

now. So today I'm going to show you how

you can take any of your editin

workflows that you already have and turn

that into a web app. And I'm not talking

about just showing you something like

lovable to build a front end and then

connecting it to your end web hook. I'm

talking about cloud code having the

ability to look at your workflow,

essentially audit it to make sure it's

ready to go for an app, and then make

any of the changes that you need on the

back end before you build the front end.

But let me show you guys what I actually

mean by that. Otherwise, it just sounds

like a bunch of gibberish. So, here's a

workflow that I wanted to turn into a

web app. It takes a form submission

where we get information from a user

like product name, product photo,

avatar, features, and video setting, and

it turns that into a UGC ad with this

workflow, as you can see right here. So

what I told Cloud Code to do was look at

this workflow and then just optimize it

so I could actually use it and connect

it to a front end. And what it did is it

changed the workflow to look like this.

There are actually a lot of changes that

it made here. And I need you guys to

believe me when I said I was seriously

impressed when I saw this. So real

quick, just wanted to put these side by

side so you can actually see what it

did. On the left was the original and on

the right is what Cloud Code built. So

first of all, it switched out the form

submission trigger to be a web hook. Not

too hard, but that's what it did. So if

you remember, one of the raw inputs it

gets was a photo. So cloud code actually

realized that it's going to come through

as a B 64 string when we send it over

web hook and it has to convert that. And

then at the end what we had to do is we

had to figure out how did we want this

to be displayed in the front end. So we

basically are sending back a message

whether it was successful or not. And

we're sending over the URL so it can be

embedded in the actual landing page. And

it also changed all of these HTTP

requests to be continue with an error

output. And it routed the error to a

different branch which would send the

front end an error message. And another

cool thing to realize is that when it

changes the actual source of the input

data, it had to change the variables

everywhere else. So it really thought

about the actual node by node flow, not

just changing the input and the output.

So if you don't understand all of those

changes that I just explained and like

why that's important, it's not a huge

deal. The point I was trying to make

there was just showing you that Claude

will look at your workflows and fix them

for you before you ever turn them into a

front end. And you guys know that my job

is to make complex or intimidating

things as simple as possible. So that's

exactly what I'm going to do today.

We're going to walk through it all step

by step and you're going to realize how

easy it actually is. So, real quick

before we get into that, I just want to

do a quick demo of the final product of

this that took me basically 40 minutes

where I started with this workflow.

Cloud code turned it into this workflow.

And now we have this front end where I

can put in the information. And let me

just show you guys a quick demo. So, I

put in some information, I put in a

product photo, and I'm going to go ahead

and hit generate. And now, what happens

is it basically tells us on this right

hand side that we have this one job

processing. If I go into the actual end

workflow that it's hitting right now and

I go to executions, you can see that

there were some failures when I was

doing testing and stuff. But what we're

going to notice is that we get a new

execution right here pop through. And

then when that's finished, it will

automatically display right here where

we can see the video and we'll be able

to download it. So you can see that the

workflow just finished up and you can

see we have our video right here which

is displayed in the website. We can

click on this link to download it. And

also just for reference, here is the

original cologne image that I uploaded.

So you can see that it pretty much looks

the exact same. So I'm not going to be

diving into this actual workflow that

produced the results. I already made a

video about this, so if you want to

check it out, I'll link it up there. All

right. Hopefully I'm not losing you

already. I know that this workflow and

this demo may seem a little bit complex,

but we're going to set up everything

step by step from the full process of

taking an edit in workflow, optimizing

it with cloud, and then getting it onto

a front end and deploying it. Okay, so

step one is open up VS Code. This is

where I like to work with Cloud Code as

an extension because the actual visual

interface is just so much cleaner. It's

so much better and you don't have to

look at your nasty terminal or anything

like that. VS Code's been around for a

long time and it's a very trusted

platform. So once you're in here, you're

going to click on this lefth hand side

and go to extensions and then you're

going to type in up here cloud code.

Once you do that, just click on cloud

code and then go ahead and install it.

And when you install it, it should

prompt you to sign in with your

Enthropic with your cloud account. And

that's how you actually link them

together. Now, once we have that

extension installed, we actually need to

start up a project. So, what I'm going

to do here is I'm going to go to the

lefth hand side and go up to this button

right here, which is the file explorer,

and it says you have not opened a folder

yet. So, go ahead and open one up. So,

I'm in my documents. I'm in a folder

called Aentic Workflows. And then I'm

drilling down to another folder called

Nadent app, which has nothing in it. So,

it's a blank folder. It's a blank

project. And I'm going to select it,

which now gets us into this environment.

So, you can see up top we've got Nident

app, which is our project. And on the

lefth hand side over here, we're going

to see all the other files that we add

to this or that get created. In the

middle is where we're going to actually

be chatting with Claude Code. And the

way we do that is by clicking on this

little Cloud Code extension button right

here and then closing out of whatever

else we don't want. And on the right

hand side is where we have the actual

like VS Code agent chat, which means we

can talk to this agent about like what's

going on in here. And honestly, I never

really use this because the Cloud Code

agent is smart enough. So that's kind of

the interface we're looking at. I know

it may seem a bit overwhelming right now

because there's lots of new buttons and

there's lots of places to look, but I'm

basically just going to tell you guys

about what you need to know. And if you

follow this demo all the way through, by

the end of it, you'll have a really good

understanding of what you're looking at

and how to work with cloud code. All

right, so the first thing that we want

to do whenever we start up a new project

is we want to give it some sort of

guidelines about what are we actually

doing in this project. And the way we

actually do that is we just have to

create a file, which is essentially the

system prompt. And it's going to be

called claude.md.

And so what you could do is come over to

the lefth hand side and you could click

on new file. You could type in claude.md

and then we could basically just start

working in this file or we could have

claude itself edit the file. And the

reason why this popped up over here is

just so we could view it. You could

close it. You could open it back up. You

could open up like 10 different files at

the same time if you want to. But let's

just keep our screen clean and keep open

just the cloud code for now. Okay. So

what I'm going to do is have cloud code

help us write that cloud.md file. So,

let me just read out what I actually

wrote to it. So, I said, "Help me create

a claw.md file in this project to set up

what we want to do here. This project is

essentially built to help me turn my NDN

workflows into apps." So, there's going

to be a few pieces. The first piece is

going to look at my workflows in NN to

make sure that they're ready to go as

far as having the right intake of data

and output of data so that if it's a web

app, when the app sends data to NN, it

can properly receive it. And that also

when NN sends a response back to the

front end, it's properly displayed. Just

like we saw here in this example, I

wanted to make sure that when NN sent

the response back to the app, it could

be displayed as an embedded video. And I

also wanted to make sure that when we

sent over a JPEG file to NN, it could

receive it properly. Then I came back

and said once we know the workflow's

optimized, then we have to start

building the front end. So we're going

to start building it and testing it in a

local environment and then once we like

how the app looks and functions, then

we'll push it to GitHub. And GitHub is

basically just a home for our code and

it will let us do different versions and

see all the changes. And then what

happens is our code lives in GitHub, but

then we're going to have Verscell sync

up to it. And Verscell is where we

actually deploy those apps on the web.

And I have a diagram to break this down

in a few minutes here, but essentially

the idea is we work in cloud code, we

push changes to GitHub, and then our

actual real web app on the public URL

always reflects the most recent version.

So it's just super easy. So there's also

a couple things that we're going to

utilize. One of them will be the niten

mcp so that you can understand nitend

nodes configurations templates and you

can look through my niten instance and

create and edit workflows and things

like that. I'm also going to give you

access to two skills the niten skills

and the front-end developer skills. And

I'm going to give you access to the

GitHub MCP so you can actually push

changes to my GitHub. And then I finish

that off by saying with all that in

mind, ask me any questions that you may

need and help me make this file concise

so that we keep everything neat and

lean. So before I send this off, I

wanted to talk about these different

modes. So right here you can see I'm on

bypass permissions which is orange. We

could go to ask before edits which is a

lighter orange. We could go to edit

automatically which is white. Or we

could go to plan mode which is blue. And

so whenever I'm doing something like

this or whenever we're setting up an

initial prompt I always like to use plan

mode because it thinks a lot better and

it asks you questions and it basically

just lets you guys have a conversation

before you actually do anything. So, I'm

going to go ahead and shoot off this

prompt in plan mode, and we're going to

see Claude Code think about what it

needs to do. It's going to first look

through the current structure to see if

there's any files. It's going to

understand what we're doing here. And

you can see right here, it said before I

draft the file, I've got a few

clarification questions. So, what's the

typical structure of the workflow you

want to turn into an app? Right now,

let's just say various triggers because

we don't actually know what we want to

turn into an app yet. For the project

structure, do you have a preferred

project structure in mind? I'm just

going to say propose structure,

whatever. I don't really care. Repo

strategy. Should each workflow become

its own repo in GitHub? Yep. We'll just

do separate repos, one for each app. And

then for styling, we'll just go ahead

and go with Tailwind CSS. And if you

don't know what this stuff means, you

can just go ahead and ask it to. That's

the beauty of Claude code is that we

don't have to really understand all the

code and exactly what it's doing. We

just have to be able to communicate our

thoughts clearly. And if we get

confused, just ask Claude what it's

doing and why because it's really good

at that. So you can see it gave us this

plan for the cloud file and I said,

"Yep, that sounds good." I'm going to go

ahead and auto accept and now it's going

to update this cloud MD file which right

now has nothing in it as you can see and

it's going to basically just write in

the system prompt and you can see that

it just happened in real time right

there. Okay, our system prompt is

configured. So next what we have to do

is give it access to all of those things

that we mentioned like the skills, the

servers, whatever the MCP. But before we

do that, let me just show you guys

exactly what we're doing here on a

whiteboard so it all makes way more

sense. So in my last video, I showed you

guys how we can use cloud code and give

it the end mcp and the end skills to

build workflows for us in our own end

instance. So we're kind of building on

top of that here. If you haven't watched

that video, that one might be a good one

to start with and then come back to this

one. So I'll tag that right up here. But

essentially the end mcp gives cloud code

access to all the nodes, configurations,

workflow patterns, things like that. and

ended in skills gives cloud code all the

knowledge about expressions, how to use

this MCP server, how to code, all this

kind of stuff. So the TLDDR is you're

essentially giving one of the smartest

brains in the world access to all of the

information about NN that you could

possibly need. So now we're building on

top of that and we're creating web apps.

So what we do here is we've got once

again cloud code with MCP servers and

with different skills and now what we

wanted to do is create us a web app. So

in order to create that web app first of

all we use end to see the backend

automation that we want to turn into an

app and we create the front end to

actually like collaborate with that. Now

what is the front end? It's actually

just code. So cloud code is building the

code that displays the website and what

we do with that code is we push that to

GitHub in something called a repository

or what a lot of people just call a

GitHub repo. And then we have Verscell

which actually deploys it on the

internet so that other people could

access this app. and Verscell is

constantly looking at your GitHub repos

so that if anything changes over there,

you can basically have that change be

instantly reflected on your real app. So

like with this web app, the actual code

for this lives in my cloud code locally.

It's also reflected on GitHub and then

Verscell has deployed it. So let's say I

wanted to make this green instead of

blue. I could tell cloud code to change

the code to make it green and then I

could say push this to GitHub. So,

GitHub would grab it and then Verscell

would grab it from GitHub and then in

like 20 seconds we would see that this

website would be green instead of blue.

Hopefully that architecture makes sense.

Now, let's get back into cloud code and

let's start connecting all these things

that we need. So, now what I'm doing is

I'm saying connect all of these MCP

servers and skills and just let me know

if you need anything else. So, I'm

giving it the URL for the NIN MCP

server. I'm giving it my cloud URL. I'm

giving it my NIN API key. I'm giving it

the GitHub MCP server URL. I'm giving it

my GitHub personal access token. I'm

giving it the repo for my the end skills

and I'm giving it the repo for the

front-end design skills. All of these

links that you'll need, I'll just put in

the description of this video. And what

I'm going to do is I'm going to turn

this on bypass permissions mode because

I just want it to go without me having

to approve everything. So, I'm going to

go ahead and shoot this off and let it

work its magic. And while that's

running, I'll show you guys two things.

The first one is how do you get bypass

permissions mode if you don't see it

natively right there? Well, you go to

your settings down here and then you

would type in clawed code and then right

here you just have to turn this check

mark on that says allow dangerously skip

permissions. Now, I know it sounds

dangerous, but it's not too bad as long

as you're watching it and like, you

know, making sure that you're not

telling it to go delete all your files

and things like that. Now, the second

thing I wanted to show you is how to get

your GitHub personal access token. So,

here is my GitHub. All you have to do is

just go to GitHub, create an account.

It's free to create an account. And then

you're going to go up here to your

settings and then at the bottom of your

settings you should see developer

settings and you're going to go ahead

and create one of these personal access

tokens and you'll create a fine grained

token. So that's all you have to do.

It'll give you basically an API key and

then that's what you're going to give to

claude code here so that it can set

everything up. And when you actually go

to create this token pretty much just

give it a name. I leave mine on public

repositories. I change the expiration to

never. And then the last thing is about

permissions. And usually what I do is I

just add all of these. There might

there's like 23 or something, but just

add all of them. If you realize later

you want to restrict something else, you

can just go ahead and create a new one

or restrict it in cloud code. It's not a

huge deal. And then generate the token

and pop it over to cloud code. And so

the other thing to look at, and

throughout this tutorial, you might see

me use like a slashclear or some other

things, but if you hit slash, you can

see that there's other things that we

can look at. So we can attach a file, we

can mention a file from a project, we

can switch the model. So we can go from

default or sonnet 4.5, opus, haiku. We

could also turn on thinking. We can

manage our MCP servers, agents, hooks,

memory. We can do all of these other

slashcomands as well. And then if you

actually use cloud code in something

like cursor or in the terminal

environment, there's even more commands

and like more things you can do with

agents and like plan mode and things

like that. But like I said, VS Code just

makes this all look a lot cleaner and a

lot less intimidating, which is why I

wanted to do cloud code on VS Code in

this tutorial. So now it's asking me,

how would you like me to configure all

of this stuff? I'm just going to say

create the MCP JSON file because I don't

want to do it myself. I just want you to

go ahead and take care of all of this

stuff. And that's the thing that's

interesting about this because when you

go to a lot of these MCB servers or

skills, it'll basically tell you

installation steps and it will say,

"Hey, go add this to your cloud code

file or hey, go install this plugin."

And I don't want to actually do that. I

just want Cloud Code to do it. So, all I

do is I give it the raw URLs. And what

you can see here is when I give it the

raw URLs, it just uses its web search

tool and it reads the page and

understands installation and then just

does it. So a lot of times if cloud code

comes back to you and says, "Hey, what

you need to do is do this." You can come

back to it and just say, "No, you do

it." And most of the time it'll just do

it. Every once in a while it'll say, "I

actually can't. I need you to do this."

But most of the time you can just tell

it to do it for you. Like right here it

says, "Install the skills by running

these commands after restart." I'm going

to say, "I don't want to install those

commands. Can't you just do it for me?

And what do you know? Done. Both skill

sets are now installed. So I didn't have

to do any of that. So right here we have

the MCP JSON file. And this is where you

can see we have our NADN MCP server and

we have our GitHub MCP server. And

you'll notice that we don't actually see

the skills in here. And the reason why

is because the skills were installed

globally, not just within this one

project that we're working in called

endent app, which is cool because later

if we make another project, we already

have those skills installed. And if you

don't believe me or you get confused,

you just ask Claude. I said why don't I

see the Niten skills in this project and

it basically just came down and said

yeah they're installed globally here are

the seven skills and for some reason it

said six so not the best at counting but

then we also have the front-end skill

down here so that's just to prove that

they are actually installed even though

you don't see them over here on the file

explorer now something else to keep in

mind about this MCP JSON file is that it

has your real GitHub token and your real

API key in here. So if you've shared

this file for some reason or someone had

access to this, they would be able to do

anything in your end because they have

this information. So obviously I'll be

deleting these credentials after this

video goes live. But just something else

that I wanted to make sure you guys were

aware of. That is why typically when

you're doing certain things, you're

going to have like av file and you'll

have your actual scripts and things call

on those credentials so they only use

them when they need them and like all

those files are encrypted. So don't want

to confuse you guys. We're not going to

dive into that right now. Just something

that you should be aware of. All right.

So, what I'm going to do now is I have

to restart Cloud Code, otherwise it

won't actually reflect all that. So,

really what I'm going to do is just

close out of VS Code and then we're

going to open it back up and then

everything should be all set. All right.

So, I'm going to go ahead and do a slash

command. I'm going to do /cle just to

get rid of this conversation so we can

start fresh on a new context. But keep

in mind, every time we talk to cloud

code, it's still going to be reading

through our cloud. MD system prompt to

understand what we're doing in this

project. Okay. So, what actually are we

going to turn into a web app? Well,

let's make it pretty simple. I've got

this workflow here which is just an AI

agent and it's a chat window here and

it's called fitness coach. So, in here I

basically just have a system prompt

prompting this agent to be a fitness

coach with stuff like um you know

weightlifting, working out, some basic

nutrition stuff just so we can make a

little demo here. But you can see that

this is not ready to go to be turned

into a web app. Not really at least. But

all I'm going to do is just tell Cloud

Code to look for this workflow and help

me turn it into a web app. So, we're

going to go back into cloud code. I'm

going to change this to plan mode

because we want to like brainstorm how

we're going to do this. And I'm going to

say, I've got a workflow in my edit

instance called fitness coach. I want to

turn this into a web app. So, before we

do that, please take a look at it and

help me change it so that it's ready to

go and I can talk to it from a front

end. So, I'll shoot this off and we're

basically just going to watch it think.

It's going to walk through its steps and

what you can see right now is that it's

using the end MCP to find our workflows.

Now it was able to find the fitness

coach. So it's going to analyze it and

you can see that it found the workflow

but there's an issue which is it's using

the chat trigger which is not really

designed for a custom front end. So it's

going to write up a plan to change this

workflow for us. So here it asks, do you

want the fitness coach to remember

conversation history? Because right now

in the actual workflow there's no

memory. So what I'm going to do is say

yeah that's a great feature. We want the

coach to be able to remember like it's

having a conversation. Okay. So, here it

came up with a plan which is to prepare

the fitness coach workflow to be a web

app. So, it tells us what the problem

is. It tells us what it's going to do.

So, it's going to replace the chat

trigger with a web hook. It's going to

add a window buffer. It's going to add a

window buffer memory. It's going to

update all these connections. It's going

to configure the agent input. And then,

it's going to publish the workflow as

well. And so, we could obviously make

some changes here if we want. I want to

see how it did on its own. So, I'm going

to go ahead and just auto accept all

these changes. I'm going to make this

bypass permissions so that we can just

basically see when it's done. And what

it does is it creates a to-do list,

which is really cool because it helps

the actual model stay on track, but it

also helps us understand its thought

process and what stage it's on. So that

way, a lot of times when you're working

with Cloud Code, you can have it open on

one monitor, you can be doing something

else, watching a YouTube video, whatever

you want to do, and just kind of

checking in and making sure that it's

staying on the right path. And a lot of

times it's not perfect, but what's so

cool about cloud code is that it runs

into issues and it analyzes what went

wrong and then fixes it. So right here

you can see that there was an error

because the key parameter for the

session ID for the memory was was

missing. And so it figured out that the

body is actually nested and then it went

ahead and just you know changed the

workflow after it realized that. So it's

all about how much context you give it

and how clearly you can explain what you

want. And that's also why the planning

mode is so helpful. But it looks like

that workflow has been updated. Now,

what I'm going to do is go back into

edit end, which was this workflow right

here. And I'm going to hit refresh, and

we should now see that the workflow is

changed, and it should be ready to go

for our web app. So, we've got a web

hook, which is post request. We've got

our memory, and let's see if it changed

the actual configuration of the user

message, which it did. So, we also, I

noticed, don't have a responder web hook

node. So, what it's doing is it's using

respond when the last node finishes with

the first entry. So, I think we should

be all right. But later if we end up

needing to change something, we would

just say, "Hey, Claude, this didn't

work. Go fix the workflow." All right,

so back in Claude, what I'm going to do

now is I'm going to clear out this

context once again, and I'm going to go

back into plan mode, and we're going to

talk about what we want this actual web

app to look like. Hey Claude, help me

create a plan to actually build out this

front end for the end workflow. I want

to make sure that in your plan, you're

going to be using the front-end designer

skill, the end tools skill, and all of

the resources that you have to make this

as good as possible. We don't want the

web app to look AI vibecoded. We want it

to look professional, very minimalistic,

and we want it to be super clean. We

also want it to be a little bit gamified

to incentivize people to come in and to

talk to the fitness coach. Maybe we can

have the main chat interface and then on

the right hand side, we can have a

little bit of gamification with um a

tracker for how many times people have

talked to the fitness coach and maybe

they can level up after, you know, every

five or 10 messages or something like

that. Ask me clarification questions to

make sure that we're not leaving any

holes in our plan here and any

suggestions that you may want to make

that I didn't yet think of. All right,

I'm shooting that off. I'll let you guys

know if anything important happens. All

right, so I got some questions here. The

first one is which end workflow should

this front end connect to? We're going

to do the existing workflow, which it

should be able to find. Now we have what

core features should the fitness coach

provide when users chat with it? General

fitness Q&A, personalized workout plans,

progress tracking. Yeah, we'll just do

all of these. gamification. For the

gamification system, what should users

be leveling up and earning rewards for?

Just a message count. Let's just do

that. And then what's your preference

for user data persistence, remembering

their level, message count, things like

that. And I'm just going to say, let me

decide later. We can get into a bunch of

back-end database storage and, you know,

authentication in different videos. We

want to keep this one simple. So, for

now, we're just going to go with that.

Now, it's asking for the name or ID of

the existing Fitness Coach workflow, the

one that it found earlier. So, I'm just

going to go ahead and type in the name

or ID. And honestly, now that I think

about it, it probably would have been

better if I didn't clear the context and

we just kept talking on that previous

thread. But what are you going to do?

Some more questions now. What color

scheme or brand aesthetic do you want?

I'm going to go with dark mode primary.

The app name, let's just go with yeah,

fit coach AI. And then mobile layout.

Should the gamification panel be visible

on mobile or only larger screens? We're

just going to go with always visible.

Keep things nice and easy. All right.

So, the plan for the Fit Coach AI web

app is done. There's tons of stuff in

here with structure, text stack, key

features, all this kind of stuff.

Obviously, you would [snorts] read

through this and make some changes if

you want, but we're just going to see

how Cloud Code does on its own. So, I'm

going to go ahead and auto accept those

changes. And of course, what it's going

to do is set up a to-do list, as you can

see right here. So, I'll just check in

with you guys when we have something

ready to test. Okay, so there we go. The

to-do list has been completed and Fit

Coach AI is ready. You can see that it's

actually living right now on a local

host, which basically just means only we

could access this. So if I gave you this

exact, you know, HTTP address, it would

pull up your own local host, whatever

you're hosting on 30002. So what we need

to do is make sure it works here. And

then you can see when you're ready,

we'll initialize the git and we'll push

it to GitHub and then we'll deploy it to

Verscell. So I'm going to go ahead and

open up this local host and let's take a

look at what we've got. All right. So,

this is the Fit Coach AI interface that

it came up with. And you can see we've

got ready to crush your goals. You can

try creating a 30-minute HIT workout.

What should I eat after working out? How

do I stay motivated to exercise? We've

got some stats over here. So, we've been

a member since January 14th. We've got

rookie level one, 11 points to the next.

We've got a road map. So, it did

everything that we were looking for.

Let's see if it's actually able to talk

to our NN workflow. So, I'm going to

start off by just saying, "Hey there.

We'll shoot this off and let's see if we

get some sort of response back. Okay,

cool. So, it gave us a response, but it

doesn't look great as you can see

because what happens is in nitn when we

respond, we get the whole JSON body. So,

we get the output and then we get all

this other stuff. So, if I actually go

to the fitness coach workflow, we go to

executions, we can see that when claude

code changed the workflow, it did

everything right, which is great. But

the actual output of the fitness coach

is this JSON body. So basically the

front end displays this JSON body rather

than just the actual output which is

what we want it to display. So super

easy. What we're going to do is we are

going to of course go back into cloud

code and just tell it to fix that. So

what I'm going to do is take a

screenshot of this output just so that

cloud code can see exactly what I'm

talking about. We'll go back in here.

I'll paste that in. So it's working

good. But when the agent responds to us

in the app, it actually displays the

entire JSON body. We don't want to see

the field called output. We just want to

see the actual output itself.

And for something simple like this, I'm

not even going to go into plan mode

because it's a very easy request. So, it

should just be able to change the front

end to configure just displaying the

actual output. All right, sweet. So, it

said that it fixed that. I'm going to go

back in here and I'm going to say,

what's the best time of day that I

should be working out and eating? So,

just something random. Shoot that off.

And hopefully this time we only get back

the actual output that we're looking

for. Another thing that I am noticing

though is nothing's actually happening

on the gamification side. So, I imagine

that this should be giving us points

each time that we get a message back. As

you can see, we did get a better output

now. Although, I don't like that it's

coming with like markdown and bold. So,

that's something that we would actually

change in the system prompt of the agent

here rather than in the front-end

development. So, not a huge deal, but

we're not getting any points. So, that's

the next thing that we have to tell

Claude to fix. Awesome. That change

worked, but now the issue is we're not

actually getting any gamification. So,

I've sent two messages now, but we still

have zero points on the app itself. So,

fix that. Okay, so it looks like it

reset some stuff with local storage and

whatever this is talking about. Now,

let's go ahead and try again. It seems

like that should have fixed. Although,

now we have to see if we can refresh the

page. Uh-oh. So, this is the actual

local host that we were supposed to be

using the app on, but there's some sort

of issue here even when I refresh. So,

let me take an a screenshot of this and

send this over to cloud code. I can't

access the app anymore. Okay, so it says

that it rewrote everything with a

simpler approach. We should need to try

to refresh. And there we go. Cool. So,

we actually do have our two messages

that we already sent. Let's just say um

create a 30-minute hit workout. Shoot

that off. And hopefully when the agent

responds we'll get another point on the

right hand side. Cool. We did. So we got

the response and we also got another

message. Now finally before we actually

push this to GitHub I wanted to show you

guys that we could change the system

prompt with cloud code. So one last

request.

Awesome. That's working. My last request

is that the agent is responding with

markdown formatting and bold stuff. So I

wanted to just respond in complete

natural language paragraph form like an

actual human would. So go ahead and make

that change in the nitin workflow and

update the system prompt of the AI

agent.

All right, cool. So the nitin workflow

has been updated. It went ahead and

changed the system prompt so that now it

should only be responding in natural

language. I'm just going to go ahead and

go to the workflow and refresh it. Make

sure everything is all set. Looks like

we've got it saved. It's still

published. So let's just do one final

test in here. So I set it like that

because I want to make sure that the

memory is working. I want to make sure

that it comes back and responds to us in

natural language only. No formatting and

that once again we will get the um extra

message. Okay. So we still got a little

bit of bold things and we'd probably

just have to go back. But what I wanted

to actually make sure of was that in

here it actually did change the system

prompt which you can see that it did. So

I guess maybe we just weren't explicit

enough at actually how to prompt it. But

the point I was trying to make, which is

what I think is really important, is

that what we just did is we had a random

workflow. We had Cloud Code look at it,

optimize it for a front end. We built

the front end, and then we went back and

forth with Cloud Code when the front end

wasn't working how we wanted it to. And

then we also had Cloud Code change the

actual backend end workflow itself. So

everything that we're doing here is just

using our natural language to cloud code

and just speaking very clearly about

what we want. And that's obviously a

good example. I wasn't clear enough

about the way that I want it to respond.

So I would just have to go back one more

time. But now let's actually move on to

the next step here where we're going to

take the code and we're going to push it

to GitHub and then have that

automatically sync with forcell. So

first of all, what you need to do of

course is go ahead and go to GitHub. So

this is my GitHub. You've already made

your access token to give it to Claude

Code. But now what we need to do is

create a repo. So I'm going to go up

here, create new. I'm going to click on

new repository. I'm just going to call

this fit coach- aai since that is our

name of our app. And then I'm just going

to do dash app. Um, I'm not going to do

description. We'll just leave it public.

I'm not going to add a readme or get

ignore any of that kind of stuff. I

literally just added a name and I'm

going to create that repository. Now,

what I'm going to do is I'm just going

to take the actual URL up at the top in

my browser and copy that. Go back into

Cloud Code. We're going to go ahead and,

you know, let's just keep going in the

same context window. I'm going to say

here is the GitHub repo for this app.

Paste in the URL and say please push

this to GitHub so we can sync it with

Forcell and get it live, get it

deployed. So I'm going to shoot that

off. I'm also leaving it once again on

bypass permissions because this is a

pretty simple request. And now it's

going to go ahead and do that for us.

And now in the GitHub repo, you can see

there's nothing here. But what's going

to happen is it will get um all of our

files will be pushed to this

environment. And once again, as you're

working with GitHub and Verscell, you

can ask Cloud Code any of the questions

you may have about how they work

together or why it's important, and it

will get back to you. All right, cool.

So, the code has been pushed to GitHub.

Now, it says next steps would be to go

to Verscell and import that repository.

And then it also says to add the

environment variable, which would be our

actual web hook. But we'll we'll take a

look at that when we get there. So,

let's go to GitHub real quick. And if I

refresh this repo, we can now see that

we have these files in here. And

basically these are the files that hold

the code of our fit coach app. Now what

I'm going to do is I'm going to go to

versel which is right here. This is the

UC one that I was looking at earlier.

And what's going to happen is you can

see that this is pulling from my GitHub

repo for this code. So what I'm going to

do here is click on add new. We're going

to add a new project. And I should be

able to see import git repository. And

right here we have our fit coach AI app.

So I'm just going to go ahead and click

import on that repo. And now I could

change the name or the team or the

preset or whatever I want to do, but I'm

just going to go ahead and click deploy.

All right, cool. So, we just deployed

this project. I'm going to go back out

to my dashboard and I'm just going to

show you guys how you can get there. So,

if I go back home, you can see the

different projects that you have in your

Verscell. So, if I just give this a

refresh, we can see we have the Fit

Coach app. So, I click into that. What

you can look at here is deployments. So,

every time you have a new version, you

can see when it was actually uploaded.

We can look at our logs. We can look at

gateways, storage, we can look at all

this kind of stuff. But right now, what

I wanted to do was actually just click

on the project itself. So we can go to

that domain, which is fit

coach-ai-app.verell.app.

So if I open that up, this is what we

see. And we're no longer on localhost.

Now we are on this domain, which means

that if I gave you guys this URL, you

could access this and you could talk to

like my instance and all that kind of

stuff. So what I'm going to do is we're

just going to say, how do I stay

motivated? And what we get is a server

configuration error. And so we need to

figure out what happened here. So the

first thing that I want to look at is

I'm going to go to my actual end

workflow and I'm going to go to

executions. Now what happens here is we

don't see that execution that we just

did. So what that tells me in my brain

is that we have our front end deployed

on the web. We have ended end deployed

on the web but for some reason they're

not talking to each other. So when I hit

this button which says you know like

when I send the message when I hit that

button normally what that does is it

sends this string of text to the end and

web hook but for some reason that's not

configured. So if you remember we went

back into cloud code and it says to add

the environment variable which is the

our edited web hook and then we have the

actual web hook to hit. So this is one

of those examples like I was talking

about earlier where we have an

environment variable that only gets

called when we need it. And so the

reason why Cloud Code built it like this

is because they didn't want anyone to be

able to look at the GitHub repo and find

our URL for our NN web hook. Now, in

this case, I don't really care because

if I have a web hook, I could set up my

own authentication so that only people

that make an account can actually talk

to it. But it's important to think about

because if I gave you guys this URL and

I didn't have any, you know, web hook

security, someone could spam it

thousands of times and it would cost me

money because it's on my NN with my

OpenAI credentials or my open router

credentials. So in this case, what you

would do is you'd add the environment

variable. So you would come into where'd

my Verscell go? So we'd actually be able

to add that by going in here. We'd go to

our settings. We could scroll down here

to environment variables and we would

basically just add one and we would have

the key be nadn web hook URL and then we

put in the actual URL and that way

versell would understand to call on it

when we hit that button. But in this

tutorial I just want to keep things

pretty simple. So what I'm going to do

is just go back to cloud code and just

tell it don't do the environment

variable just hardcode my web hook in

the code because I also wanted to just

show you guys how we can push that

change instantly to forcell I don't want

to use my web hook as an environment

variable please just change the code so

the web hook URL is hardcoded in there

it's going to make it much more simple

okay so now the web hook URL has been

hardcoded into the code and we have to

redeploy that so I'm going to import the

changes to GitHub you You can see in my

forcell it's rebuilding this real quick.

And in GitHub if I refresh you can see

that now there are two commits. So every

time that you change the code and you

push it to GitHub it will have another

version here. So that way you can see

what happened each time. And now you can

see that this has been redeployed onto

our um app in Verscell. So I'm going to

go to the new landing page and we're

just going to try to ask another

question. So um design a beginner

strength routine. And this time it's

actually working. It looks like it's

writing back some sort of response

because it did hit our end web hook.

That's at least the hypothesis here.

Cool. So now it responded with much more

natural language, which is cool. You

know what I think actually happened last

time is maybe we just didn't like

publish the most recent version. But

anyways, in the fitness coach end

workflow, I'm going to refresh this.

We're going to see if we got that

execution, which is right here. And we

know it worked in this case because the

actual post request that got sent over

was design a beginner strength routine,

which is exactly what we just said in

our app right here. And I would also

feel a little bit bad if one of you guys

followed this tutorial and then woke up

with like thousands of, you know,

credits spent on your account. So

another thing you can do is they have

like a security review function in Cloud

Code. And obviously claude code with

Opus 4.5 is going to be really really

good at like reading your code and

understanding if there's vulnerabilities

which is something that you should you

know regularly just say hey by the way

like what should I be aware of and what

like risks do I have? So I basically

said here do a full security review of

anything that I've pushed to GitHub to

make sure that I don't have any

credentials exposed online because my

GitHub repo is public and my workflow is

you know out there too. So, it searched

through everything and it said, "Okay,

cool." So, your hard-coded ended web

hook is out there, which I told it to do

that. It's fine. I understand that.

And that basically just means that

people could see this and then hit the

web hook directly. So, that is a

problem. But if you set up your own

authentication on the back end or

obviously this is just a demo, so I'm

not too worried.

And the recommendation would be to move

this to an environment variable. And

then it also talked about my

credentials, which is something I

brought up to you guys earlier, which is

the fact that those are all stored in

this MCP file. So in this JSON file, I

have my credentials for GitHub and Nitn.

So if someone got this file, that could

be a big problem, too. But this file is

stored locally. So I basically said to

it, hey, why do I have to rotate my

credentials? Aren't they safe for my

local environment? And it basically

said, yeah, you're right. Your

credentials are safe. I was being overly

cautious because this file is not in the

GitHub repo. It's not online. it only

exists locally on your machine. And I

know that this project itself right

here, like this app, isn't anything too

complex or like super impressive. But

the idea is now that you understand like

this whole framework and how everything

works together, you can continuously

iterate upon this and you can maybe even

add more end workflows on the back end

using the help of cloud code, fixing

things on the front end, adding

different functionality, pushing it back

to GitHub, and then it continuously gets

better. Cuz I mean, think about it with

something like this, it's really your

imagination because you can control what

you want on here. Maybe you want

somewhere where they can upload progress

pictures or a food logger or a workout

logger, things like that. And then by

default when you deploy something on

Verscell, it'll have the domain that

ends inversel.app.

And so you will want to buy a domain

somewhere else or just buy one right

here in Verscell and connect it. And

it's pretty simple. You would pretty

much just click on this plus right here

and you could either buy a domain or add

a domain. You'll have to do something

with the DNS records if you're

transferring in a domain from like

NameCheep or Squarespace or wherever you

bought the domain. But it's super

simple. You just have to go in there and

change like an A record and it may seem

a little confusing, but just have chatbt

or Gemini or Claude walk you through it.

It's really easy. Or Claude Code. Just

have Claude code tell you how to do it.

And then the last thing I had to talk

about cuz I know there's going to be

tons of comments about this is the

Claude plan. So yes, you could 100%

start on Pro because you do get access

to Claude code if you're on the pro

plan. But I will say you probably will

reach your limit pretty quickly. But I

really wouldn't stress this. It's just

one of those things where Start on Pro.

If you hit your limit, okay, go upgrade

to the $100 a month plan. If you hit

your limit on the $100 a month plan,

upgrade to the $200 a month plan. And I

know $200 a month sounds expensive, but

if you think about how much you can do,

and if you think about how much would it

cost for me to pay like a top tier

developer to do this kind of stuff, it

is significantly more than 200 bucks. So

that 200 is going to be a huge bang for

your buck. Once again, if you're on 200

a month and then you realize you're not

using it all the way and it's not worth

it, then just downgrade. It's not going

to be permanent. Okay, so we just

covered a ton of information. So let's

just recap what we just did. First of

all, what we did is we connected cloud

code to the end MCP server to look

through how NIDin works and to be able

to go into our instance, get workflows,

create them, edit them, publish them,

all that kind of stuff. And then we gave

it access to the end skills so it

actually knows how to use that server

and how to build endto-end workflows.

After that, we were able to have Cloud

Code optimize the workflows to be ready

for a front-end deployment. So, we also

gave it access to a front-end designer

skill. We gave it access to the GitHub

MCP so that as we're building this web

app and we're hosting it and testing it

locally once we have that code ready to

go, then we push it to GitHub which

automatically syncs with Verscell and

then deploys it on the web. So, now

other people can actually access your

app. It's not just on your own local

environment. And then of course because

of this whole framework, as soon as you

update the code and push it to GitHub,

it automatically will update on the web.

And now that you're already in this

project called an event app or whatever

you called yours, if you wanted to, you

could just do another workflow in this

project because you already have the

cloud MD file. You already have your MCP

server set up. You already have your

skills set up globally. You have this

folder right here, which is all the

stuff you need for this app. But if we

wanted to, we could obviously just come

into here. We could clear out this

conversation history and we could say,

"Okay, cool. Now I want to build a front

end for this other app and just go

through that whole process again. And

because all of this is stuff that it can

look through, it could maybe even take

inspiration from other apps that you've

done in the past.

Today I'm going to be showing you guys

five simple hacks that you can use to

make sure that Claude Code is building

you websites that don't look like they

were AI vibe coded, but they actually

feel professional and branded. And we're

going to be going through this in a way

where even if you've never used Claude

Code before, that's completely fine.

you're going to be able to by the end of

this video spin up some really awesome

looking landing pages and websites. All

right, so I don't want to waste any time

at all. The first thing that you need to

do is you need to go download Visual

Studio Code. So go to a browser and type

in VS Code and download this for your

operating system. This is essentially

just the IDE that we're going to be

using Cloud Code within. So once you've

done that and you've opened it up, this

is what it will look like. You're going

to go to the lefth hand side right here

and click on extensions and you're going

to type in cloud code and install it

like what you see right here. Now, once

you do that, it's going to prompt you to

sign in with your Enthropic subscription

or your cloud subscription, which you do

need a paid account. As you can see

here, if you're on free, you don't have

access to Cloud Code. But here on Pro,

you actually can use Cloud Code. Whether

you're on pro or max, you can use it.

I'd probably just start with Pro. If you

hit limits, which you probably will if

you want to, you know, build websites

all day, then you should probably

upgrade to max. So, once you've got that

installed, you will see this little

button up here, which is Cloud Code. And

when you click on that, this is where it

opens up the ability to actually use

cloud code, talk to this little crab

agent. And this is very similar to sort

of like a chatbt or using cloud in the

web. Now, the way that this works when

you're using cloud code in Visual Studio

Code or really wherever you use it is

you have files on the lefth hand side

and then you have your agent on the

right hand side. So, first thing we need

to do is open up a project so that we

can start working with some files. So,

I'm going to go up here to the top left

and I'm going to click on explorer. What

you can see is that it says you have not

yet opened a folder. So, I'm going to go

ahead and open up a fresh folder that

has nothing in it. So, here we are in my

website building YouTube folder, which

like I said, it's a blank project. If

you don't have a folder, just go ahead

and create one. Whether that's in your

desktop or your documents, just create

one to start and then open that up. And

that is where we will be working on this

project. So, let's get started going

through these five hacks. The first one

is actually number zero. And the reason

that I did this is because the first one

is a claw.md file. And I put this as

number zero because it's kind of a

prerequisite, but also a lot of times

near the end, even after 1 2 3 and four,

you might have to rego back and update

your cloud.MD file or just have Claude

do it itself. So what is a claw.md file?

Just think of it as a system prompt.

Think of it as every time before you ask

claude code to do something, it will

read the claw.md file first. It will

always process that. So what you want to

do is make sure that that is pretty

concise. You don't want to bloat it too

much with context, but you want to give

it the rules that it needs. So, every

time you are doing something in this

project, this website building project,

do this, this, and this. And always

remember that's kind of the end goal.

And so, if you don't exactly know your

full process yet or the end goal, then

you might start without a claw. MD file.

But luckily for you guys, if you go over

to my free school community, the link

for that's down in the description, you

go to the classroom, you go to cloud

code, and right here you will see the

web designcloud.mmd file, which is the

one we're going to be using today. You

can go ahead and just download that for

free right here. Now, once you've done

that, you can actually just drag it

right over here to the lefth hand side.

Like I told you guys, the lefth hand

side is where we can see our files and

our folders. And what that does is it

opens up the claw.md file, which if I

drag over here, we can see it kind of

full screen. Now, the MD stands for

markdown, which is basically just this

right here. We've got the pound signs,

we've got um asterisks, and it just

helps keep the text organized so that

the agent can read, you know, what's a

header, what's a subheader, what's bold,

what are bullet points, things like

that. So, you could obviously read

through this entire claw.md file if you

want to to kind of understand what we're

telling it to do in this project. I'm

not going to read everything because you

guys can just, you know, look at it here

or download it. And as we go through

these other hacks, you will see why I

put some of this stuff in here. But that

actually brings me over to our first

technically our first hack, which is the

front-end design skill, which is why you

can see right here in our cloud. MD, the

first thing I wrote is always invoke the

front-end design skill before writing

any front-end code every session. No

exceptions. So, first of all, real

quick, what are skills? Well, if you go

to the cloud code docs, you can read

about skills right here. Essentially,

they are custom instructions. So, every

time you build like a custom GBT or

cloud project, you're usually putting in

knowledge and you're putting in

instructions. And basically, skills are

just that, but in a markdown file. And

why it's so important and cool is

because every time you ask Claude a

question, first it reads its cloud.mmd

file, but then it will think, okay, the

user asked me this. Do I have any skills

in my library that help me do this

better? If yes, I'll grab the skill.

I'll read it and then I'll take action.

If no, I'll just use my general

knowledge. So, that's why we need to

have the front-end skill because it

helps us create designs that are way

more modern and professional and they

don't look as much vibecoded, AI

vibecoded. And the good news is it's

super super simple. You just have to

install it. So, here's a tweet that

showed the power of this. All they

prompted Cloud Code to do was use the

front-end design skill, create a music

player app, and it created this that has

some, you know, animations, it has some

dynamic elements, and if you would have

just told Claude Code to do this without

that skill, it would have looked much

worse. So, I'll leave a link to this

tweet in the description of this video,

you basically just have to run this

command and then you run this one, and

then you should be good with the skill

installed globally across any Cloud Code

project that you might use in the

future. And when I say run these

commands, you can literally just copy

this if you wanted to and just paste

that right into here in cloud code and

it would install that for you. All

right, so let me go ahead and show you

guys how good this front-end design

skill really is with such a minimal

prompt. So before we prompt this agent,

I just wanted to show you guys something

else you can do, which is kind of a

bonus hack. What I'm going to do is I'm

going to create a new folder. I'm going

to call this brand_assets.

And our claw.md file actually explains

that this might be a file or a folder

that cloud code needs to look at. And

what I'm going to put in here are two

things. My logo and brand guidelines so

that it creates this website and it

feels very branded towards me and my

business. So right here I'm dragging in

the AI automation society logo as you

can see like that. And then I'm also

going to drag in our brand guidelines

which has stuff like our colors, our

typography icons, stuff like that. And

so now that Claude can look at that, I'm

going to just give it a very very simple

prompt. So, all I'm saying is build me a

modern and professional landing page for

AI Automation Society. And I'm also

going to tell it that here's my logo and

here's my brand guidelines. It would be

able to figure it out either way because

we put it in the claw.md. But I just

wanted to show you guys that you can

actually tag assets directly. So, if I

do an at, it will basically pop up and

let me choose or point at the right

things. So now I can explicitly say,

"Hey, here are the, you know, here's the

brand guidelines and here's the logo

because maybe they're not named in a way

that's super intuitive and now I'm just

showing Cloud Code exactly what I want."

So I'm going to shoot this off. I'm not

even in plan mode. I just want to show

you guys how good this front-end design

skill is. And what you're going to

notice is first of all, what it did is

it read the clawenmd file and now it's

reading the brand assets. And now what

it's going to do is it should hopefully

invoke the front-end design skill and

start building out that website for us.

There we go. right on Q. It has invoked

the front-end design skill right there.

All right, so that has finished up. You

can see that we've got a nav, a hero,

tools marquee, we've got stats, about

benefits. So, a full onepage landing

page, and it should be completely

matching our brand as far as the logo,

the colors, and the typography. It also

added some animations. So, I'm excited

to see how that works. And it threw it

on local host for us to check out. So,

let's head over there. All right, look

at that. We've got like a little

animation up here. We've got a line

going down. We can see that we do have

our logo up here as well as our exact

colors and font. We've got a community

rating. Oh, that's super nice. We've

also got some scrolling tech companies.

So, we've got edit end make, Claude,

GBT40, Zapier, Air Table. We've got some

random stats here. Obviously, we'd have

to fill this in with our own copy, but

keep in mind all of this happened with

only us saying, "Create me a landing

page for our community called A

Automation Society." That was literally

it. And it created all of this. We've

got testimonials. We've got a final call

to action here. The logo is doing a

little floating for basically a one

sentence prompt. This is super super

solid with the front-end design skill.

Now, there was another secret thing

going on here that I didn't yet tell you

guys about, but if you've already read

the Claw Denm, you might have noticed.

And that brings us on to hack number

two, which is the screenshot loop. So,

the idea here is that AI is really good

at getting you where you want to go, but

it takes a lot of manual correction and

steering. So, let's say I just told

Claude Code to build us that website.

Without the front-end design skill, it

might have gotten us like 40% of the way

there. But now that we added the

front-end design skill, it's going to

get us maybe let's let's just call it

60. What we can do now is use

screenshots to help AI iterate upon

itself. So, instead of it getting 60% of

the way there and then we make an

improvement and then we make another

improvement and we keep doing this, it

basically should just bridge this gap

itself because it's able to take a

screenshot, look at the browser, see

what it looks like, and then make make

changes. So, what you guys didn't

notice, or maybe you did, is over here,

it created a new folder for us called

temporary screenshots. And we can see

that in that process of building out

that first version of our workflow, it

took 10 screenshots. So, I can click

here, and I can see what it looked at.

It looked at the hero section, which

kind of was a a random full page. It got

the viewport, which was that's more of

the hero section. It looked at the

stats. It looked at the about page. And

what it did is it used these screenshots

as it kept clicking through and looking

and improved things. So, you guys didn't

see this, but in the actual to-dos, it

wrote the index. HTML, it started the

server and screenshotted the workflow,

and then it did a two pass screenshot

review and polish. So, it basically uses

its eyes to check that what it's

building actually looks good. And in

order to set that up, it's actually

really, really easy. If you go to the

cloud.md file, you can see that I've got

a section for screenshot workflow. And

we're just doing this using Puppeteer.

So, literally, if you take this cloudMD

and say, "Hey, Cloud Code, can you set

up Puppeteer to take screenshots?" It

should be able to install all of that

stuff for you right there really simply.

And so, yes, that's cool on its own, but

where it actually comes into handy a lot

more is when we look at hack number

three, which is using other websites as

inspiration. Because what we're able to

do is say, "Hey, Claude Code, take this

website right here and build me a

clone." So, you should build one that

looks exactly like this one. And then

what it's able to do is use its eyes,

use its screenshot tool to screenshot

what it's building and look at the

reference and keep going back and forth

until it's close enough. So, let me show

you guys that in action right now. So,

there's tons of sites that you could go

to for website inspiration. Here's one

example called Dribble. Here's another

example called godly website. And here's

another really cool example called

Awards with three W's. So, there's tons

of places that you can find inspiration.

So, for the sake of this video, I found

this one that I want to use. It's got a

nice little animation in the background.

It's obviously not our color scheme, but

it has some cool things as you scroll

down like a dashboard. It's got some

other little cards down here. None of

this is really too animated. Well, I

guess that is. But let's just say we

wanted our website to look like this

one, for example. First thing that I

would do is I would hit F12. I'm on

Windows, by the way. I would go to

console and I would do control shiftP

and search for screenshot. What this

lets me do is capture a full-size

screenshot of the entire page rather

than just my current view. So here you

can see it downloaded this screenshot

and you can see that that is indeed the

entire website. Now, if you're on Mac,

that's still doable, but you just have

to Google the different buttons to do

it. And then the next thing what I want

to do is on the top right here, I'm

going to go to elements, and in the

style section down here, I'm just going

to copy everything. So, I'm actually

copying basically like the raw code or

HTML or, you know, whatever you want to

consider this as that tells the website

how this is styled. And we're going to

give Claude code that. So, I'm going to

go ahead and do a clear so we can start

a fresh session. I'm going to first of

all just paste in the code that we just

copied which is the style information.

So I said I want you to spin up a new

website for us. Get rid of the old one

and you can put this one on local host.

I basically want you to clone this

website. So I'm going to give you the

screenshot which what I'm going to do is

just drag it in from my files and put it

right over here. As you can see that is

the screenshot we just took. And I'm

going to point to it so it knows what to

use which is the www right there. And

then I said here's a screenshot. Here's

the style. and just go ahead and clone

this website for us. So, that is all

we're going to do to start and then we

can come back in later and tell it to

use our branding and our, you know,

colors and logo and everything like

that. Now, a couple things to keep in

mind. When you're doing some of the big

processes like spinning up a website

from scratch or comparing two websites

and cloning them, that coding process

and thinking will take longer. But once

you have a working version, making small

changes or tweaks, that happens pretty

quickly. And one other thing is you

might have noticed that this really

isn't stopping to ask me questions. And

that's because I'm using bypass

permissions mode. So if you don't see

this in your instance, you're going to

go to settings. You're going to type in

clawed code. And then right here, you

should see allow dangerously skip

permissions. And that is where you turn

that on. Now I definitely have a

responsibility to tell you that this is

dangerous. It has the potential to just

kind of like run any command that it

wants. But in my practice, I've never

really had this be an issue, especially

because I'm never like setting this to

code all night long and then going to

sleep. I'm always still kind of like

watching it or I'm nearby and nothing

bad really is going to happen. All

right, awesome. So, we just got to the

point where now it is creating a to-do

list. And what you can see here is once

it actually writes the code for the

website, it's going to start up the

server and it's going to take

screenshots and it's going to do two

rounds at least of comparing. It's going

to look at what it built versus the

reference. It's going to fix any

mismatches and then it's going to do

that again. And that is why the

screenshot loop is so powerful. So

logically, this is really cool. I mean,

it's going through and it's looking

section by section and analyzing how

well it's stacking up. But we will have

to see how it actually turns out. Okay,

so that just finished up and before we

actually see how good it really built

this, I wanted to point out one thing

about the screenshots. So you can see

that we have screenshot 1 2 3 4, all of

this kind of stuff. But we don't really

know which one is which without clicking

on them. So, it looks like these are the

clones as you can see because they're

coming out looking like the website that

we gave it. Well, we either should have

before we started this new build, we

should have told cloud code, hey, you

can delete all of those temporary

screenshots or in the claw.md, we should

be more specific about the naming

convention of the screenshots so that we

can actually tell. Now, realistically,

these temporary screenshots are more for

claw codes benefit than for ours, but

that is something else that you can be

thinking about if you do want to be able

to click through and see the changes

that were made with each version. But

anyways, let's go ahead and open up this

link and see what we got. All right, so

I'm going to switch this to English for

my head. But we can see we've got the

purple colors. We've got your strategic

ally for a truly profitable business.

We've got the same top menu bar. Um a

similar type of dashboard here. We've

got some cards. And as we scroll down,

it feels very similar to the real

version that we gave it, which was this

one. Obviously, some of the dynamic

elements in the background and some of

the actual images could not have been

the exact same, but for a clone, this is

very, very similar. And it is a really

good spot for us to actually start. And

now we can just start to integrate our

own colors and logos and copy right into

this template. And it's as simple as

just asking it to do so. So, I'm going

to go ahead and clear this out. I'm

going to say go ahead and delete all of

the temporary screenshots in the

temporary screenshots folder. And so now

all of those have been deleted as you

can see. And we're basically going to

say the most recent landing page looks

really good. What I want you to do now

is work in our brand assets. So our

brand guidelines and our AIS logo. And

this is for our community called AI

Automation Society. So just work in

those changes to that website clone that

you just built. And once again, we are

just going to stay on bypass

permissions. I'm going to shoot that

off. One shot prompt this thing. And

hopefully we should get something that

looks pretty solid. Now, what I'm

interested to see is what it ends up

doing with this dashboard and what it

ends up doing with this iPhone screen

because we haven't given it any other

pictures. As you saw in our website, we

obviously gave it some different

pictures like the school games dashboard

or me with Hermosi and Sam Ovens. But

that's what you could do is you would

come back into Cloud Code and you would

say, "Hey, I gave you some more pictures

in the brand assets. Put this one here.

Put this one there." And it would figure

that out for you. And of course, you

would also have to say, "Cool. When they

click on start for free, take them to

this link." or when they click on see

the demo, take them to this link. So,

there's other little pieces that you

would obviously have to configure as

well, but those changes take basically

no time. Okay, so that finished up

pretty quickly. We've got three

screenshots here, but I'm not going to

click into them because I don't want to

ruin the final reveal here. But we used

our colors. We have our primary accent,

our secondary, our dark background, and

our mid background. We've got the right

typography. We've got the right logo,

and everything was fully translated from

French to English. Thank goodness. And

now it's rewritten for our community,

which once again, we didn't actually

give it facts about the community yet.

This is just very simple prompting. It

also mocked up a dashboard. So, let's

head over to our local host. Let's give

this a hard refresh. And boom. We now

have our new site, master a automation,

build faster, earn more. For the

dashboard, it worked in like a little

bit of a it's got members. It's got

automations, courses. It's got it's kind

of like a community tracker dashboard,

and it uses our colors in there, too,

which is cool. We've got different

things on here, workshops, templates,

expert community. It also changed this

iPhone thing to member growth this

month. So, it's keeping all of this on

brand with the actual original reference

site, which once again looked like this.

However, now it has our colors and it

has our information in here. We've got

two paths and then we have some other

stats down here and a nice little call

to action at the bottom. So, cool. What

we could do now is obviously go back and

forth a little bit, maybe change some

text, make things bigger, you know,

change the images and stuff like that.

But let's say we're at a spot where we

like the overall feel and vibe of the

website. But now, how do we really up it

to the next level to make it feel

unique? Well, what we're going to do is

unlock the final hack, which is

individual components. And what I mean

by that is taking inspiration from

different places, but for very

individual components, for small pieces,

not entire websites. So, what we can do

is we can go to a website called

21st.dev,

which has some of the best website

components you might be able to find.

It's got shaders. It's got backgrounds.

It's got home screens. It's got buttons.

It's got, you know, mouse highlights.

It's got so many different things that

you can do. So, here you can see I've

got buttons and I could make them have a

rainbow outline. I could make them

shiny. We could toggle, you know, dark

mode or light mode. There's lots of

different things we could do here. Or I

could just click on backgrounds in here

and I could look at other ways that we

could have our background. So, maybe we

want these little kind of drop down

pills instead. Or maybe we want these

hero waves in the background. I think we

should actually do this instead. So,

what I'm going to do is just copy this

prompt right here. This will basically

copy a chunk of code for us to give to

Claude Code. And I'm just going to say,

I want you to work in this background

element right behind the hero text. And

after I give it that prompt, I just

paste in what we grabbed from 21st. And

it should be able to use all of this and

understand how to put that into our

site. So, I'm just going to go ahead and

shoot this off and we will see.

Actually, one thing that I forgot to

mention is in this case, because we're

working with an animation, the

screenshot might not always work the

best. So, sometimes you might want to

tell it not to do the screenshot flow.

So, I'm basically actually just going to

copy all of this text once again. I'm

going to clear this out. I'm going to

paste it back in. But then I'm also

going to say

because this is an animated background,

do not use the screenshot tool to

compare. just work in the code and then

I will let you know if we need to make

any changes. So hopefully with that

mentioned even though it's going to read

the claw.mmd it won't do a bunch of

screenshots here because I've actually

tested this out and I've had you know

different background elements come

through and because they're dynamic

sometimes the screenshot doesn't fully

capture it. So it gets stuck in this

loop of thinking I haven't built this

good enough. I'm going to keep trying

and it like overengineers and it just

doesn't really work. So sometimes you

may want to turn off the screenshot

tool. All right, so that just finished

up. It didn't take a bunch of

screenshots, so it didn't take forever.

Let's go to the website. Let's give it a

refresh and see. Okay. Okay. So, we've

got a background. It looks a little bit

um distracting. It also looks a little

bit cheap. It looks like too pixelated.

So, what I'm going to do now is just

iterate. I'm going to tell it that

I think that it's a little bit

distracting as far as it makes the hero

text right behind it a little bit tough

to read. Also, in the hero text, I'd

like it if the earn more was maybe a

blue or a different color. I think that

doesn't really feel good to have that be

orange. It would be good if there was

maybe some sort of background behind the

hero text so that we could see it and it

would still stand out and contrast

against the background animation, but

the background animation looks super

fuzzy and super pixy. If you could make

that look a little bit more professional

and clean, that would be great. And if

you guys were curious why I was just

like staring at that and talking is

because I was dictating and I wanted to

be able to look at what I was talking

about. So we've given some feedback now.

Let's see if it can go ahead and make

those changes. And once again, like

we're being pretty vague here and it

would be up to the creativity of the

model to understand what we're asking

for and be able to make these changes.

Now, if you were on plan mode, it might

be able to do a little bit better job of

asking you some questions and maybe

helping you get to a better solution

first before it starts coding. But for

the sake of the video, let's see how

well it does with this prompt. All

right, that just finished up. And you

can see that that looks much, much

better. This is definitely more what I

was looking for when we copied over that

animation into this website. So from

here, we would just keep going through

and we'd keep being really nitpicky

about what we want to change. We'd add

our own pictures in. We'd maybe want to

change some of these buttons to be more

dynamic. We'd want to maybe animate some

of this other stuff, which we could

easily do just by asking Claude Code to

do so. So from here, the question is,

how do you actually get this onto a real

landing page? Because right now, we're

still developing all of this code and

we're previewing this in our local host.

So what we're going to do is we're going

to use a combination of GitHub and

Verscell to do this. Cloud code is where

we're working right now. All of these

folders, all of these files are local,

meaning if I pulled up my laptop, I

wouldn't be able to access them. And

when we're building our website, which

is obviously this website right here,

this is all made up of a bunch of code

in our cloud code project. So what we

need to do with that is we sync that

code to GitHub and GitHub has version

control. We can see all of our commits,

other people can work on it, stuff like

that. We basically host our code or our

project in the cloud and we set up a

really cool autodeploy between Verscell

and GitHub. And Versell is basically

just where we deploy our code to a live

site. So basically what this means is

whenever we tell cloud code, hey this

looks good, push these changes to

GitHub, GitHub grabs the new changes and

then Verscell automatically grabs those

from GitHub and then updates the real

working version of our site. And I will

show you guys that. But let's first of

all do this pipeline. So the first thing

that you're going to need to do is go to

GitHub, create an account if you don't

already have one, and you're going to

need to create a new repository. So I'm

going to create a repository right here

called AIS test website. I'm not going

to worry right now about a description

or all of this and I'm just going to go

ahead and create that repository. Now,

what you also could do is you could tell

Claude Code, hey, create me a GitHub

repository and it could actually do

that. But right now, I just wanted to

show you guys so you can get a feel for

GitHub if you've never used it before.

So, anyways, now we have this repository

called AIS test website. I'm just going

to copy the name of that real quick and

I'm going to come back into Cloud Code.

We're going to clear this out and say

awesome. So now that this site looks

good, we need to actually deploy this on

our domain. I need you to help push this

to GitHub and we're going to push it to

a GitHub repository called

and then I'm going to paste in the name.

Now, so far it has not yet gotten our

GitHub credentials. So we're going to

have to obviously authenticate into

GitHub first so it can push that into

GitHub. So I just got logged in as Nate

Herkai and now it's going to create the

ignore and get everything set up so it

can actually do so. Now, it's not too

big of a deal right now because nothing

that we'd be pushing into the public

GitHub or, you know, onto the cloud has

API keys or has any usernames or

passwords or any sensitive information

or, you know, web hook abilities. But

that is something to be aware of once

you actually are pushing automations and

things like that to the cloud. Make sure

that you're not putting any of your

sensitive information out there.

Awesome. So, it now says that our site

is live on GitHub. So, if I click into

this link, we should see that we now

have a new commit. We have all of this

stuff like our claw.mmd. We have our

screenshot stuff. We have brand assets

and now we can sync this to Verscell. So

that would be step two is you're going

to go to versell.com create an account.

When you create that account, it's much

easier if you just sign in or create

that account with your GitHub

credentials. And then all we have to do

is go ahead and add a new project and

then we're able to just choose a GitHub

repository. As simple as that. So I can

literally just hit import on our AIS

test website which you guys just saw me

set up. And then all I have to do is go

ahead and deploy this project. Awesome.

So I've deployed a new project to my

project. I can go ahead and continue to

the dashboard here. And what this now

does is we can actually visit this by

going to ais-test-website.vercell.app.

I open that up and now this is no longer

local. I could open up my phone and type

in this. You could open up your browser

and type this in and you guys could all

visit this site because it's now

deployed on the cloud. But of course,

it's got an ugly domain. So what you

would have to do now is you would have

to go to your project settings. You

would go to domains. And then this is

where you would actually just have to

either buy a domain right here or add an

existing one. And it's really simple. It

would walk you through the DNS

configuration that you need to set up.

And it's not too difficult, but I'm not

going to actually do that live in this

video. So, what I wanted to show you

guys real quick before we end off this

video is what actually happens if we

realize that we want to make a change to

our website that is on the cloud. Well,

that's why it's good that we still have,

you guys can't see because you can't see

the URL, but we still do have our local

version because if I make a change here

and I don't like it, I don't want that

to automatically get pushed to um

Verscell. So, what you'd probably want

to do is in your claw.mmd file, you

would say ultimately what's going to

happen is we're syncing all of the

changes to GitHub. GitHub's going to

automatically push them to Verscell and

we'll be good to go. But when I'm making

changes with you here, we're always

going to test on a local host until I

tell you explicitly to push that to

GitHub or commit those changes to

GitHub. Okay. So, this is our local

version. And let's just say, for

example, we wanted to make this button a

little bit cooler. So, I'm going to ask

in Cloud Code, could you go ahead and

make the join the community button in

the main hero text section, make it more

professional. So, give it like a cool

glow. And once you've made this change,

let me see it in local host. Don't push

it to GitHub until I tell you to. This

thing is getting pretty screenshot

happy. I may have to adjust the wording

in the cloudmd file a little bit. It

literally took one of the main screen

and then it took one of where it just

cropped the actual button, but hey, it

looks good. Okay, so what happens is

here's the local host. I'll refresh

that. Now we can see the little glow

behind the join the community button and

here is the web app version. I refresh

this and we don't have that change yet,

which is great because we don't want to

push changes if they're not good, right?

But now what I'll do is say awesome. I

love that change. Go ahead and push that

to GitHub. All right, so it just pushed

that. We have a new commit. If I go to

GitHub and I give this a refresh, we can

see that we should see right here two

commits. This one was add glowing pulse

effect to hero join the community

button. And then if I go to Verscell and

we go to our deployments, we should see

that we just got a second one come

through as well just now. And now if I

go to the site on the web and I refresh,

we see the actual glowing join the

community button. All right, so those

are the five hacks that I wanted to

cover today. We have our claw.md file,

which as you could tell by this video,

yes, it's nice to have something to

start, but you are going to continue to

iterate upon it throughout your project

until you get to a good spot. We've got

the front-end design skill, which is

just like way too easy to not use. We've

got the screenshot loop, which you got

to be careful about, but it is very

helpful. We've got inspiration websites,

and then we have inspiration individual

components, and now it's just a matter

of making small tweaks and iterating

upon your website. Just a reminder, you

can grab this claw.md file for free in

my free school community. The link for

that is down in the description.

So, you know how on Apple's site we've

got the product, we've got quotes come

in, we've got dynamic elements like

this. We can see sort of like the

deconstruction of the product itself.

And all of these features on the website

give it a super professional and branded

feel. And I'm sure that some of you guys

have realized by now, but this website

is not Apple. This is one that I built

with cloud code using this new skill in

like 30 minutes. So, I'm going to show

you guys today the exact process to

build sites just like this that are

super professional, that have these

really nice animations going on, and

they just feel awesome. I'm also going

to be giving you away the skill and

everything that you need to do this for

completely free so that even if you've

never opened up Cloud Code or, you know,

built a website before, you will be able

to do exactly what you're seeing on

screen. So, let's not waste any time and

get straight into the video. Okay, so

we're using Cloud Code in Visual Studio

Code. So, if you don't have that, just

go to the browser, type in VS Code, and

download this for your operating system.

and it's completely free. Once you're in

here, you're going to go over to the

left, which is the extensions button.

You're going to type in Cloud Code and

install this one. It will then prompt

you to sign in with your Anthropic

subscription. And by the way, you do

have to be on the paid plan, so either

the Pro or the Max in order to use Cloud

Code. Now, once you've got that

installed, you're going to click on this

button up here, which is the Explorer,

and you need to open up a folder. So,

just go to your desktop, go to your

documents, open up a brand new folder,

just call it, you know, 3D website

testing, and then open it up right here.

So, here you can see this is the project

that I've been working in. And I've just

called it animated websites. And what

I'm going to do is give you guys all the

skills in here that you need in order to

just replicate what I'm doing. And I'm

giving you guys all that for free, of

course. So that once you have that, all

you have to do is give Cloud Code a

video. For example, here we have a video

of a camera. You can see what happens is

it just basically spins around and then

it kind of like goes into X-ray mode and

we can see inside the camera. And now

that Cloud Code has that, you just say,

"Build me a website for this video." And

what you get is something like this

where we have Vans 1. You can see it

looks like a product landing page. As we

start to scroll down, the camera is

revealed. And as we continue to scroll

more, we get dynamic text that comes

through as well as the actual camera

animation starting. And the crazy part

is I didn't give it any of the copy. I

didn't give it a color scheme. I didn't

give it any information about the

product. Obviously, you could, but what

it will do is it will just basically

create this for you and then you can go

ahead and make the tweaks that you need.

So, the two skills that you're going to

need to go grab are the front-end design

skill, which is the one that I grabbed

from Anthropic. It was an official

skill, but I changed it a little bit.

So, this is like kind of my version of

the front-end design skill for this

specific use case. And then you're also

going to need to go get the video to

website skill. So, both of these skills

are literally just markdown files.

They're markdown files that I've worked

on that tell Claude Code the best

practices for creating these animated 3D

websites. And you can get these skills

for completely free by going to my free

school community. The link for that is

down in the description. You'll go to

the classroom, you'll go to the skills

section, and you'll be able to find all

of them right in there. And literally

all you'd have to do is take them from

your downloads folder, drag them over

here to the lefth hand side, and then

just basically tell Claude, "Hey, set up

this folder." So I've got myclaude.

Within that claude, I've got a skills

folder. And then within that skills

folder, here are my two skills I need

you to use. And it should look something

like this on the lefth hand side. Now,

before you get too overwhelmed, if

you've never used Cloud Code before,

it's super simple. Right here, we have

our actual agent that we talk to and

have conversations with. And over here,

we just have folders. So, I just showed

you where the skills live, which is in a

docloud folder within a skills folder.

But then the other stuff in here is

super simple. Here are all the video

files that I've used to make the

previous websites. And then for each

website, it created its own folder. So,

for the camera website, it has all this

information. For the watch website, it

has all this information. And for the

Yeti website, it has all that

information as well. But anyways, if you

just follow the steps that I take in

this video, it will all make sense and

you will get a nice output. And by the

way, if that's a bit confusing, then

definitely go check out my skills video,

which I will tag right up here. And then

once you understand that, hop right back

over here. All right, so I'm going to

walk you guys through this process step

by step so you can see exactly what I

did to create these really cool

animations. And what you need to

understand is that all of these

animations that you're seeing on the

site and all the other ones that I've

shown, they're just videos. And so all I

did here was had Nano Banana generate

two different images for me and then

turn it into a video. So, for example,

that first one with the Apple Watch is

just the Apple Watch kind of opening up

and then exposing all of its layers. And

then when I wanted it to close back up,

I just prompted it to do the opposite.

And now we have the second one where it

goes from that end frame and then kind

of like folds back in on itself and

reveals the Apple Watch. So, now that

you understand how simple this really

is, let's go over to Nano Banana and

start making some images. Okay, so the

way that I like to use Nano Banana,

whether I'm doing it in a playground

like this or over API, is with key.ai AI

because I found that it's really fast

and it's like really cheap. So I went to

Nano Banana 2, the new version of Nano

Banana, and I came in here and did a

16x9 aspect ratio image, and I said, I

need a professional studio grade image

of a blender. It should be against a

plain all black background with no

shadows, no hands, no reflections. And

this is essentially going to be our

start frame when we make that actual

video. So then I saved that output,

dropped it in here as an image input and

I just said the exact same prompt, but

this time it should be filled with fruit

and juice. So now we have our start

frame over here and our end frame and we

just need to animate it so that it

actually looks like fruit and juice is

you know being dropped and poured in. So

then I found the best results using

cling 3.0 which once again you can also

access in this key.ai. So we give it the

start frame, we give it the end frame

and here's what I did for my prompt. I

actually went over to Claude and I gave

it the start and end frame and said,

"Help me make an AI video prompt where I

want the lid to float off. I want fruit

and juice to be dropped in. And then I

want the lid to be put back on. No

shadows, no hands, no reflections." It

spits out this prompt. I put that into

Cling. And here's the result. I haven't

watched this yet, so hopefully it's

good.

Okay. Interesting. I mean, obviously, we

maybe want to fix that a little bit, but

I'm fine with that for the sake of the

demo. the fruit and juice kind of just

magically appear from nowhere and now

they're in the blender. Okay, so I

downloaded that video. I'm just going to

drag it over here to the lefth hand side

and you can see right now that this

video that cloud code is looking at is

the exact one that we just generated

together. So this is what it's going to

use. It's basically going to take that

video, pull out like 120 frames or

however many frames make up that video

and then it's going to have all of those

saved. So just as an example, if I go to

the frames from the watch, you can see

it created over a hundred webp pictures

from that actual video. And it's kind of

like stopotion animation where each one

just changes a little bit and as you go

through the actual video starts to form.

So it basically associates each of these

frames with a scroll position. So as you

scroll down it kind of like reveals

itself or if you scroll backwards it

goes the other way. So now I'm going to

make sure that my agent is on plan mode

which basically means it won't actually

do anything. It'll just read things and

it will help create a plan which is

going to result in much better websites

on the first try. All right, so I

started off by saying I just dropped in

a video called blendercling.mpp4.

Help me create a one-page product

landing page for this product. It should

be modern. It should feel very

professional. It should have smooth

animations and design throughout. All of

the text should be easy to read. And the

background of the website should be

completely black. It should be a dark

mode. and it should blend into the

background of the Blender Cling image so

that it looks like it was one, you know,

fluid web page. So, if you were really

doing this for a product or for a

business, you'd probably want to prompt

it with some more information. But, I'm

just going to show you guys for now how

this works. I'm going to shoot that off

in plan mode, and you will see that it

naturally comes back and asks me some

questions. Now, if you're wondering how

I was able to speak right into my cloud

code, then check the description for my

tool. Now, one thing you'll notice once

you read through the way that this works

is that you will have to have FFmpeg,

which basically just extracts frames

from videos. It's a free tool, and if

you don't have it installed, Claude Code

will help you install it. It'll just do

it for you, so don't worry about that.

But now, you can see it's asking us some

questions. So, the first one is, what is

the product name and brand for this

blender? And I'm just going to go ahead

and say create fictional branding, just

like it did for the Vanta 1, which was

the camera website. Then it says, what

kind of content sections do you want?

I'm just going to go with the full

premium, which is what we've been doing

for the other example sites. But of

course, this is where you could

customize it a little bit to fit your

needs. And if you've never used Cloud

Code before, what's happening here is

you are basically able to look at

everything that Cloud Code is thinking

and doing. You can see a task, you can

see a glob, you can see what it's

reading, and you'll see later when it

actually starts implementing things,

it'll create itself a task list or a

to-do list, and you can actually watch

it fulfill those to-dos. So, it's really

cool. Okay, so now we at the point where

the plan is done. We've got Obsidian

Vortex premium blender landing page.

We've got the brand identity here. So,

Obsidian, Obsidian Vortex. The tagline

is annihilate everything. The accent

color is blood red. And we've got fonts.

We've got the video details,

implementation steps. So, here is the

ffmpeg thing I was talking about. That

will extract the actual frames. Then it

will build the HTML. Then it will create

all these different sections. It will

build the CSS. It'll build the JS. And

then it will test locally. So, before

this actually goes anywhere on the web,

we will test it right here. And then if

we're good with it, we can push it to

the web. And I'll show you guys that at

the end of the video. So I'm actually

just going to make one more suggestion

and then we'll let it start building. I

want to say this looks pretty much

there. There's one thing that I forgot

to mention, which is that I want the

product video to be kind of right

aligned. So I want it to be on the right

2/3 of the page and all the text can be

left aligned. And this is just to show

you that you do have control over the

way it looks. So I'm going to go ahead

and shoot this off. It's going to come

back with another plan and I'm going to

accept it and then I'll check in with

you guys when we have our first

iteration of this website done. And by

the way, now that I've accepted the

plan, I put it in bypass permissions

mode so that it can just continue to run

without stopping all the time to ask me

questions. Here is the to-do list that I

talked about. It's going to go through

and make sure that all of these are good

to go. All right, so in just a few

minutes that came back and it says, as

you can see, the site is live at

localhost. Open it up in your browser

and check it out. So let me go ahead and

open this up and we will see what we

got. So, you just saw the Obsidian

loading. We've got Obsidian Vortex. It

looks really clean so far. Now, let's

see what happens when I start to scroll

down. So, we see the blender starts to

appear. Nice. And as I continue to

scroll, we have we didn't build another

blender. We engineered a force of nature

that reduces anything to nothing in

absolute silence. As I keep scrolling,

we can see that the fruit is starting to

appear. So, we've got meet the obsidian

vortex machine from aerospace grade

stainless steel blah blah blah. There's

also text in the background as you can

see that says I think it says obliterate

everything. So that's pretty cool. We've

got brushless motor. We've got titanium

blade array. So that actually kind of

pops in a little bit late as you can

see. As I'm scrolling it pops in a bit

late. This one comes through. And then

we've got these stats that come up.

Really nice. And then we have the last

blender you'll ever own. And then I

should have the CTA right here which is

own the force. Pre-order the Obsidian

Vortex. So let's just actually think

about that. I dropped in a prompt that

said, "Here's a video. Create a onepage

landing page." That was basically it. It

used the skill and it created a plan for

us. And then we actually had a website

where pretty much everything is perfect.

Obviously, there's a few things that we

need to iterate upon, but this is super

super clean and the animation I think

looks really good. But the the biggest

problem that I'm noticing is right here

when we scroll to number two feature, we

really don't get to see it unless we

scroll back down. So, what I'm going to

do now is I'm going to go ahead and

clear this out because we're at 53%

context, so I don't want to mess with

context rot. And I'm going to once again

go back into plan mode. All right. So, I

just tested out the Blender website and

it looks really good. I do have one

piece of feedback though. When we're

scrolling down and we see the features,

feature number two doesn't actually

appear until it's basically off the

screen. So, we need that to actually

come into view a bit earlier. But

besides that, all the other features,

features 1, three, and four are working

well. So, I'll shoot that off. And while

it's coming up with a plan, I just want

to make sure that that was accurate.

Feature three looks good. And we don't

even have feature four. So, hopefully it

can understand, read through the code,

and see what's going on. So, while this

is creating a plan, I thought that I

would real quick explain the difference

between local host and actually having

something on the web. Because if you've

never built a website before in cloud

code, that part might not click yet. So,

what happens is we kind of have two

different environments. We've got our

local computer and then we've got the

actual cloud. So remember when cloud

code said, "Hey, cool. Your website's

live. You can go ahead and test it on

localhost port 51006."

If you right now typed this into your

browser, you'd probably get nothing. But

I can type it in because it lives on my

machine locally because what's going on

is cloud code is helping us write all of

the actual code because that's really

what a website is. It's a bunch of code.

Whether that's HTML or JS or CSS or

whatever it is, it's code. And so what

we're doing right now is we're using it

to build code and then we're testing it.

And then we're going back and forth on

our computer until we're good. And then

once we actually like the code, we push

it to somewhere on the cloud so that it

can actually be viewed by other people.

So I'll cover this pipeline once we

actually get to that stage in the video.

But I thought that I would address this

kind of like local thing first real

quick. All right. You can see it came

back with a plan to fix the Blender

feature number two late appearance. I'm

just going to go ahead and accept this.

Okay. So it did that really fast. I'm

going to click into this website and

we'll see if that fix has actually been

changed. We've got feature one. We've

got feature two. There we go. And we've

got feature three. And everything else

still looks intact with the site. So all

of the magic that's happening here is

once again within the skill that I

built. So it is the video to website

skill. If I open this up, this is

basically just a markdown file and it

says turn a video into a premium scroll

driven animated website. So this is

where all the secret sauce really lives

on how it actually does this. I know

that this is a pretty beefy skill, but

hey, I mean, it seems to be working

pretty well. And what you can do now is

every time you're using this skill to

build websites, you would just say,

"Awesome. Here's what I told you to fix.

Here's what I like. Here's what I don't

like. Make sure that all of this is

reflected on the skill.md." So

essentially, every single time that you

build a website with this skill, the

skill gets better and better and better.

Now, we have our code that we like, and

it's time to push it over here. So, what

we need to do is we're going to use a

combination of GitHub and Versel. GitHub

basically just lets us store code. So

basically the same way you would have

maybe like a word file locally on your

computer. If you wanted other people to

be able to use that, you would have to

put that on one drive or you know uh

Google doc so that other people could

look at the different versions and

collaborate on it. And then what happens

is we sync up Verscell to our GitHub so

that we can actually deploy that code

onto a real URL so that it's no longer

just like a local host URL. First thing

you want to do is go over to GitHub and

create an account. It's completely free

and it has been around for tons and tons

of years. It is a industry standard for

code. And then the second thing that

you're going to do is go over to

Verscell and create an account over here

as well. So what's cool is we can

basically have cloud code do this entire

pipeline for us. It's super super

simple. So if you haven't yet connected

your cloud code to your GitHub, you

would just come in here, maybe clear out

the conversation and say help me connect

to GitHub so that I can push this code

base to my GitHub repository. And what

it can do is it can help you basically

use the CLI to authenticate. Meaning it

will basically just have a popup for you

and all you have to do is sign in. It's

super simple. So here you can see it

says you're already authenticated with

GitHub as Nate Herkai. Nice. Now the

next step is to say awesome. Now let's

go ahead and create a new GitHub

repository for me. You can just call it

blender- website and push the codebase

for the Blender website into that

repository. Now because we're pushing

something to GitHub and because it's

going to go on the web, this is where

you'd want to be careful if you had like

API keys or anything sensitive in there.

In this case, we have literally nothing

to worry about, but that is something

just to keep in mind. All right, nice.

So, your Blender website is now live on

GitHub. Here's everything that it did.

And it also says if you want to connect

this to Verscell for auto deploys, you

can import the repo from the Versell

dashboard. So, first let's just check in

on this GitHub repo. We can see that

this has been set up. We have one

commit, which is the one that we just

did. And that's important because every

time we make a change, we can see

exactly what happened to the code here.

Now, what you'll notice is that this is

a public repository. You could go into

the settings and you could make this

private and it would still be able to

auto deploy to Verscell, no problem. And

now that we're in Versell, all I have to

do is come here to projects and click on

add new. And then what you'll notice is

right here because I've signed into

Verscell with my GitHub, it says import

GitHub repository. And all I can do is

choose right here blender- website.

Click import. And this is automatically

just going to build up this site for us.

So I'll hit deploy. And then we'll let

this spin up. And I'll show you guys

that this is now accessible on the web.

Awesome. So, you just deployed a new

project to Nate Her projects. Let's go

ahead and continue into the dashboard

here. All right. So, something

interesting just happened and I'm glad

it did so I can show you guys how to fix

it. So, our project is now here on

Versell and when I click into the

domain, everything seems to load up,

right? Right. We've got Obsidian Vortex.

We see the animations come through, but

as I start to scroll, where's our

Blender? We still get the text coming

through. We still get all these

animations that we were looking for, but

our Blender is not there. So what

happened was when it pushed this GitHub

repo, it excluded the frames. So if I

come over to the lefth hand side and we

go to our Blender project and we open up

the frames, you can see that all of

these were grayed out, which basically

means everything got pushed to GitHub in

this folder except for the frames, which

means when the site tries to render it,

there's no frames to actually render. So

what I did is I said, "Okay, that didn't

work. You need to have the frames in the

codebase so that it can actually use it.

Otherwise, the animation just

disappears." So I told it to update

those changes, make another push. It

fixed that and then basically it came

back and said okay I did that now the

frames are in the GitHub repo. If I go

to the GitHub repo you can see that we

now have two commits. If I click into

the commits you can see nice the second

one added animation frames for Verscell

deployment. And then in Verscell if I go

to deployments you can see that we had

two. We had this current one that I

rolled back to so I could show you guys

and then we have this main production

one which I could go to and we could

actually roll up to this one. So I could

click on these three dots and then click

on redeploy. And now that I have

redeployed, if I open up this Blender

website one more time and we come down

and we start to scroll, we can now see

that the frames are being rendered and

we still have all of the animations that

we had built. And now the site is

actually ready to go. And just to prove

to you guys that this really is on the

cloud, you can see on my phone we have

the Blender website with the animations.

Now, obviously, this hasn't been yet

optimized for mobile, which would kind

of be the next step, but you can see the

animations are still here. And if it

hasn't quite stuck yet, here's the

advantage of doing it like this. Now

that we have our site on the web, which

maybe customers would be looking at and

interfacing with, what if we wanted to

change something like the colors or

maybe even change the animation, we

don't want to be changing what's

actually out there in production in real

time. So, we can change the code, we can

test on a local host, and then once

we're finally good with it, we push it

to GitHub and then it automatically

syncs to our real domain. So, that way

we have basically a testing environment,

a staging environment, and then we have

our actual production website. And what

you guys saw is that this literally took

me like 30 minutes. And obviously if I

spend another 30 minutes, the site could

be like five times better. And this is

crazy because there's so many businesses

out there, whether they're local in your

area or you know, you look online that

have horrible websites because they

don't want to prioritize it or they

don't want to pay some web design agency

tens of thousands of dollars for a new

website. That could also take

potentially months. Whereas what you

could do is you could find prospects.

You could find some sort of niche. So

let's say you want to design websites

for blender companies. You could build a

demo site similar to this, right? Like

you could build something like this in

one day if you sat down and you wanted

to make it really really good. And then

you email them the link or you walk in

and you show them and say I can build

this for you with your products with

your copy and I can get that to you in 2

days and I can charge you know $5 to

$10,000 which is a lot cheaper than they

might get with other vendors. And then

of course on top of that you could do

monthly hosting, you could have

maintenance which is recurring revenue,

but it also ensures for them that if

they need any different features, you

can fix that codebase and you can push

that all up there because you understand

how this all works now. So maybe you

don't like the style of how I'm doing

this with the different, you know, text

coming through and maybe like this

animation overlay thing, then just

update the skill so that your cloud code

doesn't actually do that. And once you

now actually understand how all we're

doing is we're turning videos into a

bunch of frames and then having it

scroll through, you'll be able to do so

much more because it doesn't just have

to be product spinning or you know X-ray

vision. It can be words. It can be like

walking. It can be whatever you want.

You can also you can go to this website

awards with three Ws for some

inspiration on animations. It is super

super cool what people are doing here.

So Cloud Code is insanely smart. We've

got Opus that's kind of behind the

scenes. It's the chat model that runs

all of the, you know, thinking and

planning and coding, but it's limited

because without having, you know, web

search or without having APIs or other

elements of bringing in live data or

your specific data, it's going to be

very general. So, this section I'm just

going to show you a few tips and tricks

when it comes to using things like APIs

and MCP servers. So, let's go ahead and

jump straight in. Today, I'm going to

show you guys how you can take any

website and turn it into LM ready data

in seconds. We're going to be able to

take any website and fully scrape

everything from it. We can get all the

screenshots, the branding. We can map

out the entire site. We can extract the

data in any form we want. We can pretty

much do it all. And we're going to be

doing all of this through cloud code

using a tool called Firecrawl, which I'm

sure you guys might have heard of

before. So, within Firecrawl, there's a

lot of different things that we can do.

We can scrape content, so get everything

from the page. We can map out a site, so

get all the different URLs and

understand the architecture of that

website. We can crawl it, so then

explore all of those pages. we can

actually search. So do like a web search

first and then scrape the data which

means that we can turn pages into

structured content for us to use however

we want. Now the thing about this is

there are a lot of different endpoints

to hit if you were doing this through

traditional like API calls. So we're

going to be using the MCP server for

firecrawl. We're going to give that to

claude code so it can figure out based

on Nate's natural language request which

of these tools do I invoke and in which

order do I use them to actually get the

end result that he's looking for. So,

just to start off with a quick example,

I'm going to use Firecrawl in the

playground, which is just on the web on

firecrawl.dev. You guys can get here

using the link in the description. You

can get on the free plan, which is more

than enough to just play around. And

then when you're ready to upgrade, use

the link in the description, and you can

get 10% off a plan. But anyways, I'm

going to go to Upai, and I'm going to

copy this URL, paste that in here, and

I'm going to run a scrape. But first, we

have to choose the format. So, by

default, it'll pretty much say, okay,

we're going to turn this website into

markdown for you. But what you could

also do is get an AI generated summary.

You get all the links. You get HTML. You

could get a screenshot of the full page.

You could get the branding scraped so

you can understand like the logo and the

images and stuff like that. So I'm going

to go ahead and start the scrape. And

what we'll see is it'll pop up down

below and we'll get all of this data. So

that just finished up. We can see first

of all we have markdowns. So we get the

actual like hero text. We get all of

this stuff up here. We've got the

process. We have the testimonials, get

in touch, all of this kind of stuff. We

have an AI generated summary of what the

business aims to do. We've got a

screenshot of the entire page. As you

can see, we've got branding information.

So, the OG image, the favicon, the logo,

colors, typography, stuff like that. And

then we also have the JSON if for some

reason you're crazy enough to want to

read this. So, like I said, we're going

to get this into cloud code. So, I'm

going to click on the docs and on the

right hand side or on the lefth hand

side, we can see MCP server right here.

And then what we want to look for is

running this on cloud code as you can

see right here. And now this gives us

basically just this one line to put into

cloud code and it will be able to

install this for us. So I'm just going

to go ahead and copy this. I'm going to

go into VS Code and we're going to start

up a new project and get everything

initialized. So if you've never actually

been in VS Code or worked with cloud

code, then I'm going to link a video

right up here. It'll get you caught up

and then you can come back over here

when you are ready. So what I'm going to

do is open up a folder. So I'm just

going to open up a project called

scraper. There's nothing in here. It's a

completely new project. So this is what

your guys' setup should look like.

Lefthand side, nothing. right-and side,

open up cloud code. And I'm just going

to say, "Hey Claude, I want to connect

to Firecrawl's MCP server." And you can

do that using this command. But I'm not

going to give you my API key. I'm just

going to put it in av. So if you could

create that file for me, I will put my

API key in there. And then you can go

ahead and initialize and connect to

Firecrawl's MCP server. All right. So

that's going to go ahead and get set up

for us. You can see we now have av right

here, which is a new file. And this is

basically the best way for us to

securely put in our API keys so that

they're not being stored in like the

conversation history. So I'm going to

delete this. I'm going to go back into

firecrawl. I'm going to go to my

dashboard. And right here you can see

there is an MCP integration, but we

wanted to use the cloud code version.

And now we can see API key. I'm going to

go ahead and copy that. Paste in the API

key right there. And then I'm going to

do CRL S just to save it. You could also

go here and click file and then save

right there. And now we can close out of

that file. My API key has been added

tov. go ahead and set up the firecrawl

mcb server. So now everything should

have been set up correctly. So I'm going

to hit control shiftp and I'm going to

say developer reload the window which is

just going to actually let cloud code be

able to use this now. So just sending

off a request to make sure that that

actually worked. As you can see it was

able to call the tool and it decided to

use the scrape endpoint rather than you

know like a map or a crawl. So this is

the actual like full markdown of the

website itself. Cool. So the next thing

I want to do is give our project a

little bit more context as to what it's

actually doing in here. So first of all,

what I want to do is create a fire crawl

MCP guide so that when we ask it

something, it understands what are the

tools I have access to and which ones

should I use for what scenario. So I

said create a firewall cheat sheet as a

markdown file in this project that you

can look at and basically it should tell

you about the different tools and how to

use them. So it's going to go ahead and

create this markdown file for us. All

right, cool. So, it created that cheat

sheet as you can see right here. And if

I just open up this full screen, you can

see that we've got a quick reference

guide. We've got the tool overview. And

then it goes on to actually break down

how you use each tool. So, this should

hopefully be good enough for now Claude

to look at whenever we want it to do

something else. It even gave it a quick

little decision guide, which is pretty

nice. Now, finally, before we actually

start running with this thing is we need

a claw.md file, which is basically the

system prompts for this project. Hey

Claude, I need you to help me set up a

claw.md file for this project. I want

this to basically explain that this

project specifically is for scraping

data. Whether that is extracting it,

getting screenshots, crawling

everything, mapping everything. You have

access to the firecrawl mcp server to do

everything that you need to do with

websites. And you also have the

firecrol-cheatsheet.mmd

which explains how that MCP server works

and when to use each tool. So I just

shut that off. Now I just did want to

say this is a demo, right? So, I'm doing

this all in bypass permissions mode. But

in practice, what I would have done is

went to plan mode, brainstormed with

Claude a little bit to make sure that it

agrees with like the way that we're

setting up all these files and then we'd

go ahead and implement that plan once we

are in alignment. But as you can see, we

now have our claw.md file and this is

basically a scraper project. We have

some information about what this project

does, how to actually use the tool, what

to reference. And this document, as you

can see, is a lot more concise than the

cheat sheet. And the reason I wanted to

separate this is because you don't

actually need this entire cheat sheet to

be in the claw.mmd file, but now claude

knows that it's there in case it ever

needs to use it. Okay, so let's think

about a cool use case that we might

actually want to do with something like

firecrawl. So let's say we've got this

remote job website and I search for

content and there's about 1,700

different job opportunities here and

there's also I'm assuming not all just

on one page. So there's 2, three, four,

maybe even up to 60. So, I'm just going

to go ahead and copy the URL of this

first page right here. We're going to go

into Claude and ask it to help us out

with this. Hey, Claude. So, I found this

website and I've got about 1,700 job

opportunities that I want to look at,

but I need help using the Firecol MCP

server in order to get all of these

listed out. I want these as structured

data so I could maybe just throw them

into a Google sheet. Now, in this case,

I am going to go to plan mode because

this might take a little bit of thinking

as far as understanding the structure of

the site and maybe using more than just

a scrape. It might have to use a map or

a crawl or something else. So, we'll see

what it decides to do here. So, hope you

guys see now why I did this. It first

decided to scrape. It understood the

website and then it decided to map. And

now it's creating more of a

comprehensive plan about what to find.

It's also asking me some questions,

which is going to make this job work a

lot better. So, it asks if we want all

1782. I'm actually just going to go

ahead and say like 200 because I don't

want this to take forever. For data

fields, I'm going to grab all of them.

For description, let's just do a

summary. And I'm going to go ahead and

submit those answers. and it's going to

keep working on the plan. All right, so

looks like that is all done. We're going

to go ahead and auto accept this plan.

So I'll check in with you guys when

that's done. Now, right here is the

beauty of Agentic Workflows because it

tried to, you know, execute the plan,

but once it got into it, it realized

that something didn't work. So it said

that the extract actually returned empty

results and the site might require more

sophisticated handling. So now it's

trying out the firewall agent. So just

super cool the way that it's able to,

you know, run into an issue and then fix

it. Okay, so that just finished up and

it was able to get 200 job listings for

us. A few things happened in there, but

it it was able to just correct itself

and change up the plan and we did get

our final output. So, let me open up

this CSV. You can also see that it

dropped it in this project and we could

look at it over here, but it's not

really very nice to look at. So, here's

the actual Excel file. We've got title,

company, job type, location, salary,

experience, category, posted, how long

ago, apply URL, description, and tags.

And we do indeed have 200 of these. So

now if we wanted to applied all of

these, we've got all the URLs and we

have all this info that we need in order

to go and do that. So think about how

long that would have taken you to build

an automation in something like Nitn in

order to go scrape 200 of these job

postings. Or if you were to just do this

manually, it would have taken a lot

longer. And once again, I didn't have to

think about any of the configuration. I

just gave Cloud Code the MCP server and

let it run. We're going to do two more

really quick use cases. The first one

I'm going to do is grab Cloudbot or

Moltbot and drop it in here and say,

"Please grab screenshots of this page

and help me understand the branding."

And I'm assuming that this is going to

use the Fire Crawl MCP server. I hope it

does. And then I'm going to grab this

website, which is coffee. And I'm going

to open up a different agent on the

right hand side. And for this one, I'm

just going to tell it to map this site.

Go ahead and map out this site for me

and show me what it looks like. So now

we've got two different Cloud Code

agents working at the same time. They're

both doing different tasks and they're

using different fire crawl tools. and

then I'll check in with you guys when we

get both of these back. All right, so

the map is already done. You can see

that it comes back and it says, "Okay,

so here are all the main pages and it

gives me the links. Here are all the

different categories. So best sellers,

coffee, instant, matcha, all this other

stuff. We've got different collections.

We've got different locations. We've got

tons of different URLs for products,

brew guides, all this kind of stuff."

And so now that it has that context, I

could have it go actually crawl those

things if I wanted to or, you know,

extract all of that to a database or

whatever we want to do with it. And now

it looks like this one is finishing up

over here with the Moltbot

documentation. So the first thing we

have is a screenshot. So if I open this

up, we can see right here that we do

have a screenshot of that whole landing

page for Moltbot. And then we also have

the branding like the color palette, the

typography, spacing, and components.

We've got the logo. And you can see that

all of this was able to be done with

Firecrawl super easily. So I wanted to

show you guys all of that stuff that we

just did together, what that actually

costed me. So, I'm going to refresh my

dashboard here when we're looking at the

usage. And you can see that that took me

about 30 credits out of my 500 that I

get for free. So, 6% of my 500 credit

limit. Now, that's really the main

difference when it comes to pricing.

You've got these different plans. You've

got a different amount of pages that you

can scrape. You get a different amount

of credits. But the other big one is the

concurrent requests. So, with the free

plan, you can only be doing two at a

time. With this hobby plan in the

middle, you can be doing five. If you

scale that up, you can be doing more and

more. And it's not really a huge deal

because what would happen is cloud code

would basically just cue them up and

wait and retry. But if you did want to

do some big operations in bulk, then it

may be nice to have more concurrent

requests running. And remember, you can

use the link in the description to get

10% off your firewall plan.

You can see right here, all I said was,

"Hey Claude, I want you to take this

YouTube video and repurpose it into a

LinkedIn X and Instagram post." Then I

dropped in the link to the YouTube video

and shot it off. Not only did it create

all these assets, but it also found bugs

in its own code and fixed those. And

then we have this folder over here

called drafts. And if I open it up, you

can see that we have building beautiful

websites with cloud code, which is the

video I gave it. And then in here, we

have Instagram with our actual post text

and five visuals. We've got LinkedIn

with our post text and a visual. And

then same exact thing for X. So that

exact workflow right there took me from

having one long form YouTube video to

having a finished LinkedIn post, a

finished Instagram post, and a finished

X post. And if I wanted to ask it to

generate posts for six other social

platforms, it could because it can use

all of them and understands how they all

work. So today I'm going to be showing

you guys how you can basically 9x your

content game using a combination of

cloud code and potato. So right now when

you're creating content, you know, it

takes a lot of time and when you put all

that time into creating, let's just say

a YouTube video, it'd be really nice to

be able to repurpose that content into

different platforms as well. So what can

help you do is it can create the source.

So it can look through transcripts,

websites, PDFs. It can find inspiration.

It can then create visuals for you. So

infographics, carousels or videos. And

then it can actually go ahead and

schedule that stuff. So it can post it

to nine platforms. It can create the

stories. It can create the, you know,

content calendar. And we can do all of

that using potato and automate it with

cloud code. So you guys saw a demo

earlier, but I'm literally going to set

up a brand new account today. I'm going

to walk you through the exact steps that

you need to do. And basically all we

have to do is get our API key, add our

MCP config for potato and then just

connect our accounts and we're already

ready to start creating content in less

than 5 minutes. All right, so the way

that I like to use cloud code is within

an IDE called Visual Studio Code. Now

you could use this in anti-gravity, you

could use it in the terminal, you could

use it in cursor, but I like to use

Visual Studio Code. So if you don't have

this, then just go to your browser, type

in Visual Studio Code. You can download

this for both Windows or Mac or whatever

operating system that you're on. Now

once you're in here, this is what it

should look like. and I'm going to walk

you through everything you need to click

on and everywhere you need to type. So,

don't get overwhelmed. If you'd rather

watch like kind of an intro video and

then come back, then I'll tag this one

right up here and then hop on back over

here. And by the way, if you've been

watching my channel for a while, then

you've known about Blotato. I showed it

in Naden in this video. And also in all

of my kind of like faceless shorts

videos, we use Blot to do the auto

posting and scheduling. But now, I'm

just showing you how it's actually a lot

easier to use with Cloud Code. So,

that's exactly why once we're in here,

we're going to go over to this lefth

hand side and click on the extensions

button. And all you have to do is type

in cloud code. It'll be this one right

here that's verified from Anthropic. And

then you'll just go ahead and install

this. When you install it, it will

prompt you to sign in with your paid

Cloud subscription. Now, this does have

to be the Pro or Max plan because if

you're on just the free, you don't have

access to Claude Code. Now, once you've

installed this, what it will do is give

you this little orange button in the top

right which lets you open up Claude

Code. And this is kind of like your

typical Claude or Chat GBT interface

where you get to talk to an agent right

here. And now what we need to do is open

up a project or a folder. So I'm going

to go over to this top left button that

says explorer. And it will say you have

not yet opened a folder. Go ahead and

open one up. And that's where we'll be

working inside for this specific, you

know, AI social media poster project. So

I just went ahead and I created a brand

new one. I just called it potato.

There's absolutely nothing in here. And

this is what your screen should look

like. And now what we want to do is just

basically close out of the welcome

thing. We can go ahead and double click

and then hit the cloud code button. And

now we just have our files which will be

on the left. We don't have any yet. And

then we have our cloud code agent right

here that we are going to be able to

talk to. So what I'm going to do in the

chat is paste in this prompt that says

create me a new skill called repurpose

YouTube video. It's going to create an

AI social media manager that makes

social media posts for LinkedIn,

Instagram, and X. The user will input a

YouTube video URL and wants it I

misspelled this here to be turned into a

LinkedIn post, Instagram post, expost,

and each one should have a visual that's

optimized for that platform. So, Volt is

basically going to take this video and

do everything for us. I end this prompt

by saying, "Ask me clarifying questions

one at a time until you are 95%

confident that you can complete the task

successfully." And I kind of use this

templated prompt from Sabrina. So, shout

out, Sabrina. You guys can all copy and

paste this exact prompt for my free

school community or you can just copy it

by looking at it right here. So now that

this is running, it's going to start

going through that process. The first

thing that it's doing is it's

researching about Blotato to figure out

what it's actually able to do and it's

basically going to help us build out

this flow where we drop in a video. Blot

extracts the transcript, adapts the

content for these different media

platforms, and then it creates

everything. And then we're able to

review it and then just basically

approve it manually. Now, before I start

going through this flow of answering

questions, I wanted to explain what is a

skill because you'll notice I asked it

to create a new skill. Just think of a

skill like a recipe. If you tell your

agent to write a LinkedIn post, it would

look at the LinkedIn post skill and that

would have the name of the dish, the

ingredients, the steps, and then the

finished output. That way, the agent

could read the recipe and make sure that

every single time you ask it to make

that dish, it comes out perfect. So,

because we're turning this process into

a skill, every single time we use it,

it's only going to get better and more

consistent. But anyways, now we're going

to come back into Cloud Code and answer

the clarifying questions. So, it's

asking me what program language to build

this in. I don't really know what I want

to do here, and you may not either. So,

what I'm just going to say is whatever

you think is best. It decides to go with

Python because it's the cleanest for

this kind of APIdriven tool. So, then it

asks, should the tool autopublish or do

preview and approval? I want you to

always make sure I review it before you

ever publish anything on my social media

accounts. And if you guys are curious

about how I'm talking and words are

appearing, then check out the

description for the tool. Anyways, for

the AI generated post copy, do you want

to use Claude to write the tailored

posts or should the tool just reformat

the extracted YouTube content without an

LLM? I definitely want to use Claude to

rewrite the text content for the

different platforms. Cool. So, we'll

eventually have to give it an Enthropic

API key as well as the Blot API key.

Now, it asks about the tone of voice

that we want. So, in this case, if you

had like a custom GPT or Claude project

already that helps you write LinkedIn

posts or Instagram posts, you could just

go ahead and grab the instructions from

that and put that here. But for now, I'm

just going to keep this really simple

for the sake of the demo and just say

platform adapted, professional on

LinkedIn. Um, and on X, you can be

casual and maybe even a little bit

humorous. Now, it's asking for

Instagram. What type of post should it

create? I would like you to create a

educational carousel that looks like I

am writing tweets. And now it asks about

the visuals for LinkedIn X. For

LinkedIn, let's do a key takeaway

graphic. It should be clean and it

should have some text that explains the

value in the video. And for X, yeah,

let's just do something eye-catching.

Maybe a cool quote. Next question is,

how do you want to review the stuff?

Let's just go ahead and save everything

to the drafts folder so I can take a

look at it myself. When publishing,

should you be able to selectively

approve which platforms to post to?

Yeah, I will tell you one by one which

ones have been approved. I think I

nearly have everything. One last

question. Should the tool let you edit

the draft text files before publishing

and have the publish command pick up

your changes? Absolutely.

Okay, so it looks like we're done with

the question stage now. Now, you might

notice that there's still some stuff

that we might want to give to this

platform, like maybe some more

information about our business. It

doesn't really know anything about what

we do and maybe things like the colors

we like to use or our logo or something

like that so that it can be on the

visuals. So, now what it's going to do

is it's going to build up those

different tools. As you can see, it

makes a to-do list and it's going to go

through one by one and finish all that.

And also, what you're going to notice is

on the lefth hand side, we're going to

start to get files and folders in our

project set up. And that's really

important because if your cloud code

workspace isn't organized and it doesn't

understand where files are and if you

don't understand where files are then

it's just going to get messy and it

might be hard to manage the context.

Okay, so that has finished up. You can

see that we have a new project

structure. So over here we have a pi

cache. We've got claude with our

command. So this is essentially the

exact same thing as skills. So this is

the repurpose YouTube video skill that

it created. You can see that it created

some actual Python scripts to draft to

post to publish. And so maybe we would

want to clean this up and put this in a

different folder called scripts or

something like that. But the action item

on us now is to actually set up our API

keys. So if I go into thev, you can see

that we have a potato API key and an

anthropic API key that we need to set

up. So the first step would be to use

the link in the description and go to

and that will help you get 30% off for 6

months. Now once you get that set up,

all you'll have to do is go over to the

bottom left and go to your settings and

then click on right here API. And this

is where it will ask you to just

basically make sure that this is a paid

feature. So if you enable it, you will

be on a paid plan. And then you'll go

ahead and copy this API key right there.

And then in thev, you'll paste this in.

And then you will save it. And then it's

also asking for an anthropic API key.

I'm actually going to go ahead and use

open router instead because you can

access all the models there. So I went

into open router. I created a new key

and I'm going to copy this and paste it

into Visual Studio Code. And I'm just

going to tell Cloud Code that I am using

Open Router with Cloud models instead of

Enthropic, but you can use whatever you

want here. So, I just cleared the

context and we're about to do a test

run. But before that, I just wanted to

show you guys something that we can do

that's pretty cool real quick. So, I'm

going to go over here and I'm going to

drop in a new folder. And I'm going to

call this brand

assets. Now, what I'm going to do is

drag in a profile picture of myself in

the brand assets. It's this provo

picture right here because I wanted to

be able to use this in the tweet style

infographics or carousels that we told

it we want to make. So, what I can do

now is go to YouTube. I've got this

video I made a few days ago about

building websites in Cloud Code. Copy

the link. Come back into Visual Studio

Code and say, "Hey, Claude, I want you

to take this YouTube video and repurpose

it into a LinkedIn X and Instagram post.

I've given you in the brand assets

folder a profile picture of myself to

use in these, you know, different visual

posts. Let me know when you've got some

stuff ready to review and make sure

you're updating your skill document with

your findings from this first test run.

So now it's going to read through the

skill. It's going to execute these

different Python scripts right here. And

if it runs into any issues or anything

that we told it, like using our profile

picture, it will update that skill

document with. And here's an example of

it already needing to make an adjustment

is because it said YouTube is blocked by

the web fetch tool. Let me try

alternative approaches. So that just

finished up. You can see that it started

off by reading the skill. It goes

through and it tries different things.

It made its to-do list and it was able

to create the actual textbased posts,

but what happened was it actually failed

on the visuals. So, what it did is it

added a known issues and finding section

to the actual skill itself. But, we're

going to go ahead and try it again and

we're going to see if it can fix it. So,

I just said try to create the visuals

again. Make sure they are images, not

videos. And we aren't worried about

posting yet. We just want you to create

the assets. So, it's once again going to

dive into everything. It is going to

investigate the templates and then it's

going to come back hopefully with

something that we can review. So visuals

have been created this time and

apparently they're looking great and you

can see once again it's updating the

skill document so that that never

happens again. Okay, so these have been

created successfully. We've got our

LinkedIn with a whiteboard infographic.

Let me go ahead and open that up real

quick. It's putting all of this stuff in

the drafts folder and you can see we've

got Instagram, LinkedIn and X and this

is all for the YouTube video which is

called building beautiful websites. So

it's keeping our stuff organized. So for

LinkedIn, here's our visual. We've got a

whiteboard that says building beautiful

websites with cloud code, three key

steps. We've got cloud.md, front-end

design skill, and then adding your brand

assets to a folder. And you can see at

the bottom, it also says full

walkthrough on YouTube at Nate Herk. And

then we also have the actual post right

here, which is the textbased copy of the

LinkedIn post. So let's say we like that

one. Let's go ahead and look at

Instagram. We've got the same thing.

We've got the post right here with the

different, you know, slides, and then we

have the actual visuals. So, here is

number one. Your cloudMD file is

everything. It is a system prompt that

runs before every session. We've got the

next one, which is the front-end design

skill. And then pretty much all of these

I'm assuming are the same. We've got

brand assets. We've got you don't need

to be a developer. And then we've got

the difference between vibecoded and

professional. So, the one thing I will

say about these are that I think this

would look a lot better if we had our

profile picture as well as like a blue

check mark verified badge. So, that's

something that we'll probably want to

change. And then real quick, just to

look at the X post, we've got the actual

text itself, which is um very casual and

it's kind of more like a meme. And then

for the visual, we just have a very

simple quote. But as you guys know, I

want to make those carousels have the

profile picture in there. So I just

asked Claude Code to put our profile

picture in the carousel slides as well

as adding a blue check mark. So we'll

see if we can get the job done. All

right. So look how cool this is. It

fixed that workflow. So it now should

have new carousel slides for us. But

what it did is it actually had to resize

our image because it realized that the

potato API wouldn't take it if it was

too big. So this was the original and

then it resized it to make it smaller,

but it still obviously looks the same.

And now every single time that we run

this for Instagram carousels, it should

be able to make it the way we want it.

So let's take a look. All right, here is

the new Instagram carousel. We've got

our name, we've got the verified badge,

as well as our profile picture. And so

now it would just be a matter of

optimizing the actual content that's put

in here if we don't think that this was

prompted well enough and maybe adding

one more at the end which would be a CTA

that says like follow for more or

something like that. But keep in mind

all I said was take this YouTube video

and repurpose it. We didn't give it any

context about our business about

previous Instagram or LinkedIn posts. We

didn't give it anything but literally

just said make us content. And the only

reason I'm telling you this is because

think about how much better this will be

as you start to add more business

context, add more brand guidelines, and

then iterate and refine. We've ran this

workflow twice, I think, at this point,

and it's gotten better each time. What

would happen if we ran this 10 times,

and every time we gave it more feedback

and more feedback so that by the time

we're ready to host it, so that if we

want it to run automatically, every time

I post a new YouTube video, it

automatically gives us this stuff. By

the time we do that automatically, it's

already like a really rock solid or

battle tested skill. And by the way, in

Blotato, if you go to my videos, you can

see all of the ones that you've

generated. And you can also go to the

API dashboard to see all of the requests

that you had been making to Blot. But at

this point, the only thing left to do is

schedule these out or just instantly

post them now that we've reviewed them.

So, what you do is you go to your

settings and you have to log in with

your different accounts. And it's

literally like, let's say we wanted to

log in with Instagram. We'd click on

this and it would just bring us to a

sign-in page in Instagram and it would

connect everything very easy for us. And

then after we've done that, you can see

here I've only connected to my X

account. It lets you copy your account

ID. So basically it associates an

account ID in here with potato to

actually post on your behalf. But Claude

code using the right API endpoints

should be able to grab all those IDs for

us. So there's really nothing manual

here. So just as an example, let's make

sure that it can actually post to X for

us. Cool. That output looks great. Can

you go ahead and post our content on X

for us? All right, so that post is live.

If I open this up, we should see on X

that I did just make this tweet, which

I'm going to delete right now. But just

wanted to prove to you guys that that

endpoint does in fact work. So at this

point, now that we know this works, we

could just build different skills within

this kind of potato environment. So we

could build one for getting inspiration.

We could build one for creating, you

know, Tik Tok videos, whatever we want

to do. But before you start scaling this

up, it's really important to have some

structure to this project because we've

got, you know, our claude with our

skills, we've got our brand assets,

we've got our drafts, but we also have

some scripts right here that are just

kind of in the middle of nowhere. And we

also don't have a claw.md file yet. So,

I'm just going to go ahead and do

slashinit, which basically just reads

through the current project structure

and creates a claw.md file around what

we have right here. And I assume at this

point everyone's aware of what the

cloudmd file is, but if you're not, it's

basically the overall system prompt for

this specific project. Meaning every

time before you shoot off a message to

cloud code or before cloud code reads

it, it's going to read the claw.md file

first to understand the direction, what

tools it has at its disposal, what rules

it needs to follow, things like that.

Which means you don't want to keep your

claw.md file very long. I think best

practice is to keep it under 150 lines.

Otherwise, you're just going to fill up

your context much quicker. So now you

can see that we have a claw.mmd file

that goes over the overview, the

commands, environment variables,

architecture, patterns, things like

that, which now, as you can see, gives

our project a little bit more structure

right here. But I'm still not satisfied.

What I want to say now is we have four

Python scripts that don't have a home.

Could you throw those into a folder,

maybe call it scripts or something like

that, and make sure that our other

skills and cloudmd files are aware of

this and can reference it in the future?

And that's just the way that I decided

to set it up. But you could also say,

"Hey, you know, we've got a ton of files

here. Can you help me figure out a

strategy to clean this up so we can

continue to scale this project?" So, you

can see that it made a new folder. It

threw all of the Python scripts in

there, and now it's updating other files

in here to make sure that the whole

project understands where everything is.

So, that is going to do it for today. I

think that you guys should be in a

really good spot now set up with Cloud

Code, set up with Plot to really improve

your content game.

Google just dropped what some are

already calling the most powerful

workspace CLI on the internet. So if

you've got a ton of stuff that lives in

the Google environment just like I do,

then you're going to love this because

now any of my cloud code projects can

access everything. And all I had to do

was install one simple thing. So here

you can see I said what can you do with

GWS which is Google Workspace CLI. So it

can search, list, upload, download,

move, copy, share anything in my Google

Drive. It can do anything in my Gmail.

It can do anything in my calendar. It

can do anything with Google Docs. Same

thing with Sheets. Same thing with

Slides. And it also has multi-step

workflow recipes. So these are basically

like skills. These are chain command

patterns for common tasks like creating

docs from templates, reading sheet data,

and creating a report doc, finding free

time and scheduling a meeting. And there

are over a hundred of these that it

actually has. So out of the box, when

you give Claude Code the GWS CLI, you

can do anything across any of the tools.

And you also have access to over a

hundred skills. So I don't know how many

times you guys have tried to use

something like Claude or Naden to build

you a Google doc. And you do this over

API. And it ends up just looking like

something like this. It literally just

looks like raw markdown. And it's

obviously horrible. And sometimes to go

along with a YouTube video, I make

resource guides that look like this. But

obviously they have to be formatted.

I've got like a header up here and I've

got links and different things in this

format. But now I can literally just

take the link to a YouTube video. I can

drop that into cloud code and say create

me a YouTube resource guide. It's going

to go ahead and download that transcript

from the video. And now what it's doing

is it's creating the Google doc not via

API call, not via MCP, but via a bash

command. Meaning it's literally running

a terminal command in order to talk to

Google and make this. So it just

actually created the doc. Here's the ID.

And now it's going to populate it with

what I need. And now it finished this

up. It gave me the link. I'll click into

this. And we can see boom, we have an

actual resource guide. It's got the

image inserted up here as a header. It's

got a link that goes right back to my

YouTube channel. It breaks down the

market traditional automation. It goes

through all this stuff and then even has

my CTA at the bottom as you can see

after all these horizontal lines to join

the plus group. So that was obviously

just one quick example, but there's so

many different benefits here using this

Workspace CLI. The first one is that you

have one interface. So basically, like I

said, it was one GWS CLI that Cloud Code

now has access to and it can access my

Gmail, my drive, Docs, Sheets, Calendar,

Admin, and more. It's also JSON first

with structured responses. So, our AI

agent is really, really good at working

with it. We have auto discovery, meaning

the CLI is pretty much always going to

stay up to date automatically. Pretty

much zero maintenance because we

authenticate and then we're going to be

good to go. It has built-in skills for

triage, for prep, for generations. Like

I said, there's 100 others. And it's not

much overhead because it's basically

just one tool. It's not the same as like

having all these different API endpoints

or all of these different MCP configs

and tools that would take up more

context. But I know you're probably

wondering, what is a CLI? It stands for

command line interface. And what we're

typically used to is a GUI or a

graphical user interface where we can

see buttons, we can see form fields, and

we can click on things and that's how we

navigate, but computers are more

navigating by text and by commands and

by typing. So that's really all that a

CLI is. And this is an open- source

Google Workspace product, and obviously

it's completely free. So I'll leave a

link to this GitHub repository down in

the description if you want to check it

out, read more about it. But I'm also

going to walk through some of the key

details right here. The first thing that

I wanted to show you is if you go down

here to the skills, this is where we can

actually see all of the different kind

of recipes they call them for pre-made

multi-step workflows that it has. As you

can see, creating events from sheets,

creating presentations, creating meat

space, label and archiving emails.

There's so many different patterns that

you might use from this pre-built

library. Now, if we keep scrolling down,

what you'll also notice is that right

here it says this is not an officially

supported Google product. Now, that

doesn't mean that it's unsafe. This is

an actual Google product, but the reason

why it's not officially supported is

because right now it's more of like an

open- source beta. It's kind of a

developer playground rather than like an

enterprisebacked software. And you can

see right here that it also says this

project is under active development.

Expect breaking changes as we march

towards v 1.0. So this thing's already

really good out of the box and it's only

going to get better. And you can see,

like I said, when Google Workspace adds

an API endpoint or method, GWS picks it

up automatically. So you might as well

chuck it into cloud code right now and

start getting used to it. Okay, so I

just uninstalled this so I can walk you

guys through step by step how this

actually works. It's super easy. What I

do is I basically copy the link to this

GitHub repository as you can see. And

I'm going to basically just give it to

Cloud Code and say, "Hey, I want to

install this GWS CLI, read through the

documentation, and help me install

everything that I need to install, and

then we're going to get set up." So,

this is basically going to do all the

research for me, and then all I have to

do is follow its instructions. So, it

read the docs. It's looking at what we

already have installed. It basically saw

that I already had some of the

prerequisites. So if you don't have

those, you'll have to install those. And

then it told me that we needed to

install the CLI. So it did that. And now

we have two options. So the first one is

to install G-Cloud CLI so that we have

automatic setup and off. Or we could do

it manually by creating our own project

and whatnot. So let's just go ahead and

try option A. Okay. I thought this was

going to be just like a simple command

that it ran and then we were good. But

it's actually like some other thing to

install. So let's actually go back and

try manual and I'll just show you guys I

guess the harder way. Okay. So I'm going

to go to this link. go to our Google

Cloud Console and make sure you're

signed in with the right account up in

the top right. And I'm just going to go

ahead and create a new project just to

show you guys what this would look like.

So, new project. I'm going to call this

one Claude Code GWS. And we're just

going to go ahead and create this

project. So, this is spinning up right

now as you can see. And now that it has

been created, I'm going to select it so

we're inside of it. And then I'm going

to go up here and type in APIs and

services. Click on that. And we have to

set up our OOTH consent screen. So, I'll

click on this. and it's going to say get

started. Click on that. We have to give

our app a name. And then we have to

choose an audience. So I'm just going to

do internal because I only need this

right now for my own organization. If

you want to do external, it'll basically

have you do testing or published. And if

you do testing, just make sure that you

add your email as a test user. And then

all you have to do after you put in your

contact information is hit I agree. And

then you go ahead and create that. Now

once that has been done, you're going to

go to create a client ID. So, I'm going

to go back into APIs and services. I'm

going to go to credentials and then I'm

going to go ahead and do a create

credential oath client ID. Now, in here,

we're going to choose a desktop app. I'm

going to just call this GWS and go ahead

and hit create. And now, we have our

client ID and our client secret. And so,

what you're going to do is download this

as a JSON file. Now, you can see here

that it says to download that file and

save it to your global.config/GWS.

So, basically, if you can't find this,

just say, "Hey, can you give that to me

in a full path?" And then you can paste

that into your finder or your file

explorer and it will take you there. It

will probably look something like this.

And then you just drag in that

credential thing. I called mine client

secret. And cloud code will be able to

look at this globally now. And so what

you'll notice is that we didn't in this

project yet enable these APIs. So let me

just show you what happens without that.

So it says the last step is to run GWS

off login. So I just said, hey, I

finished option B. The credentials are

called client secret. And then I told it

to run the O login. So that should

basically open up a tab for you, but if

it doesn't, then you can ask for it to

give you that URL so that you can

actually authenticate in. So you would

basically choose your account that you

want to use. And then you just have to

basically confirm that it can access all

of these different things as you can

see. And then when you hit allow, you

should be properly authenticated. After

that, it's going to come back and say,

"Okay, cool. Let me see if everything

works." Now, this hasn't been perfect on

the first try every time, but if you

just go back and forth a little bit,

say, "Hey, that didn't work. Hey, this

is what I'm seeing." It will be able to

get you there. It's going to be your

best friend for something like this

because remember it can read all of the

actual documentation. And now it says

that the author is working, but we have

to enable these APIs in our Google Cloud

projects. So basically just clicking

open these one at a time and all you

have to do is hit enable. So it's super

simple. You just have to do this like I

said for all of these different services

that you actually want to be able to

use. So that's why I did this on a new

project cuz I just wanted you guys to

see that. But if you already have one

that has all these enabled, then you can

just use that project and generate that

OOTH client ID. So there you go. You can

see that this works. I said, "Can you

find my Google doc that I made in April

of 2025?" And I went ahead and pulled

links to all five of these because

obviously that was a very vague request.

And now we could take action pretty much

anywhere in Google Workspace super

simply with this CLI. But like I said, I

just got this set up today and I've been

playing around with it a ton in my

executive assistant project and it's

been awesome. It can literally do

anything. So here I'm asking it to grab

my unread emails from today and based on

what it knows about my business and my

priorities, give them a score. And if

the priority score is below five, just

mark it as unread automatically. All

right. All right. So, here you can see

it said, "Got 30 unread emails. Here's

my priority score based on your business

context." And as I scroll down, you can

see that it's getting different ratings.

And based on what I'm seeing right now,

this actually looks pretty good. So then

I started playing around with Google

Slides because I use Gamma right now,

but at some point I could imagine that

if this gets good enough, then I

wouldn't need Gamma anymore. And this is

a free option compared to Gamma

subscription. So I had it create me a

slide deck and it was okay. I threw in

my brand guidelines. I threw in my logo

and I said, "Hey, can you see this? you

created this using the Google slides and

it's okay but there's some weird things

that I need you to fix. So then it came

back and said I cannot see the slides. I

just know how to build them

programmatically. So that's why there

may be some errors with spacing and

stuff. So then I basically just gave it

access to ChromeDev tools so that it

could open the page, screenshot it, look

at it and then we built a plan to add

visual validation to this Google Slide

Creator skill. So now you can see as

it's going through it actually takes

screenshots and then it can make fixes

based on that. So then after it fixes

everything, it says, "Okay, cool.

Updated the skill. Take a look at it

now." So I'll open up this link. Brings

me to Google Slides where I have this

slide deck. It has kind of my brand

colors. It's got the logo up top right.

And then as we go through, we can also

see that the spacing is a little bit

better. It's still not perfect

obviously, but we have custom images

here that were generated with Nano

Banana 2. And even the images are kind

of on brand with the sort of orange and

blue color scheme. As you can see, we've

got this one with the WAT framework.

We've got this slide. And it even ends

with a CTA for the free school

community. So, just to see what else

happens, I'm going to say, "Take a look

at the slide deck and do another audit.

How could you improve the skill in the

future?" So, it's going to go ahead open

up a tab as you guys just saw. It's

going to take images. It's going to

flick through the different slides and

capture them. And as you can see over

here, it now says take screenshot. And

now, it's reading that screenshot right

there.

Now, it just moved on to the next slide.

And it's going to go through and look at

every single slide. And then, it's going

to come back with a plan. And we could

probably do a similar visual and

validate flow with creating Google Docs

as well. So now you can see it's almost

on to that last slide. And I hope it

fixes this last slide because what you

can see here is that the spacing is

really off down here. So you can see it

came back with an audit. It came back

with some future improvements. And one

thing that I did notice is that because

I made the window smaller, its

screenshots were probably worse quality.

So it said presentation mode screenshots

would probably be better. But anyways, I

just wanted to give you guys a little

taste of how you can use the GWS CLI.

but also use it with other tools to make

the functionality even more powerful.

So, just remember that this is very new.

There's a lot of people out there on

Twitter right now saying that this is

insanely overpowered. There's also a lot

of people that are saying that it just

feels kind of finicky. So far for me,

it's been pretty great. Everything that

I've asked it to do or find or schedule,

whatever it is, it's been doing that

pretty much perfectly. But there are

some people saying that it's asking them

to reauthenticate multiple times. So, if

that's a little frustrating, I guess

just keep in mind that it will only get

better and we're not even to version one

yet. So I definitely recommend that you

come to this GitHub, read about it, but

more importantly get this thing

installed in your cloud code setup and

just start using it, using it, using it.

All right, are you ready for a really

fun project? We are going to build our

own executive assistant. So think about

everything that you've done so far in

this course. We built some workflows.

We've talked about the folder

architecture. We've talked about claw

MD. We've done a lot of different

things, right? Let's turn this into an

actual system that can know everything

about our business and that we can use

all the time. Essentially, a second

brain. Now, before you guys hop into

this next one, I wanted to preface

something just to make sure that there's

no confusion. So, what you're going to

notice is that I've got some skills

running. And if you just think back to

earlier when we were building a

workflows using the WAT framework,

workflows agent tools. Skills are

basically workflows. They're basically

the exact same thing. We build out, you

know, markdown SOPs, natural language

instructions that cloud code can read

and execute on natural language. So, as

I start to talk about skills and as we

start to learn more about that, just

think of them as the workflows from

earlier in this course because workflows

have tools that it can call on. And

guess what? Skills have Python scripts

that they can call on. So, they're

literally the exact same thing. I just

like to start off calling them workflows

and tools because I think that it's just

a little bit more intuitive. So,

hopefully you guys get that, but it'll

click as soon as you get through these

next couple videos. So, let's not waste

any time. I hope you guys are excited.

Let's get into it.

This right here is my Claude Code

executive assistant. Let me show you a

few things that it can do. Okay, so I'm

going to start off by saying pretend

that it's morning because it's not right

now and use the morning coffee skill to

help me plan my day. So, I'm going to

shoot that off. Now, while that's going,

I'm going to open up a new tab and I'm

going to shoot off this message that

says, "Spin up a sub agent to do

research on the new Cloud Code voice

feature and then create both a LinkedIn

post and a Twitter style carousel for

me." It's created a to-do list and it's

getting going on that. I'm opening up

another window and I'm saying do a pulse

check on the team to see if we're on

track for the week and for the quarter.

And finally, one more just for fun.

Create me a visualization for a YouTube

video where I want to explain why having

Claude as an executive assistant is

awesome. And now it's using a

visualization skill. So what you're

watching right now are four different

agents. 1 2 3 4. All doing things for me

in parallel. And not just for a cool

demo, but these are actually things that

I do every single day or every single

other day. So, the first agent's done,

which is our morning coffee. And we can

see this is what is on the calendar for

today. That's crazy that it said March

5th. It's actually the 4th, but still

this is all correct. So, it looked

through my calendar. It looked through

my project management and our quarterly

goals. And it pulled in urgent action

items. It also pulled in my video

pipeline. So, it sees what I'm scripting

and what's in the backlog. And it uses

all of this context as well as

everything on this lefth hand side which

are, you know, current priorities, me,

OTAAS, my team, work, we've got

projects, we've got decisions, we've got

all this stuff in here that it's able to

look through. So, we've basically given

it access to everything going on in my

business and now it's able to just plan

out my entire day and I can go ahead and

say yes and it will just block off my

whole calendar. And I really love doing

this because if I don't have to have

that decision fatigue of what should I

do with my next 15 minutes, my next hour

and it's just done for me, I'm way more

productive. The second one is done. So,

we had a sub agent doing research. We've

got a LinkedIn post and we've got our

carousel. So, right here is the LinkedIn

post which is in my tone of voice as you

can see. And then if I go over here to

our projects and I go to carousels and I

go to March 4th, we can see that we have

seven slides. We've got slide one which

is you can now talk to your code editor.

Slide two cloud code voice mode is live.

Slide three. Slide four. I think you

guys get the point. And then here's

slide seven which is the CTA. Now we've

got the pulse check which is an even

deeper dive than that morning coffee

skill. It's looking at all of the

initiatives that we currently have in

progress and I can see each task and the

current status and based on all that

information and based on our goals, it

gives me follow-ups. So, I'm really

easily able to check in on the team and

make sure that everything is actually

progressing. And the last one is our

actual visualization for an executive

assistant. So, I would just need to go

to projects. I would go to

visualizations and we should see March

4th, we have Claude executive assistant

PNG. So, here's what we got. We've got

you on the lefth hand side where you're

buried in work and on the right hand

side we've got with Claude executive

assistant. And I'm actually going to use

this in the video. So, that was a quick

demo. You guys got a little bit of a

taste of what this executive assistant

can do for me. Now, don't be overwhelmed

by all these files over here. I've built

this up by using it every day, but I'm

going to show you guys exactly how you

can follow this framework to have

basically your own Herk 2, which is what

I have right here, but it would be for

you. And so, all four of these things

that just happened probably took me a

minute or two. And if I was to do each

of those manually, it would have taken

me at least 25 minutes. So, if you want

to know how you can build this for

yourself, let's get into it. So today

you are going to be building your own

executive assistant with claude code.

But I wanted to start off real quick by

just talking about what most people do

and why that's not really the same

thing. So with something like claude or

chatbt, we've been way more productive

because we've been able to save

memories. We've been able to save, you

know, maybe custom skills or custom

prompts. There's still so many times

where you've probably thought to

yourself, man, I wish this thing just

knew everything about what's going on.

So in that old way, you kind of feel

like you're repeating yourself a lot or

you're giving it extra context or it's

just helping you get maybe like 50% of

the way there instead of 90% of the way

there. But with an AI assistant, it

knows your name, your business, your

priorities, your team, your current

things. It knows the decisions you've

made. And it can also do things for you

like check in with the team. It can

create stuff. It can research. It can

plan your day. And this is the visual

that we just generated together. And I

actually like this more because it's

showing that I'm able to create more

YouTube videos because of this

assistant. So, the benefits are pretty

clear here. You can save a lot of time.

You never have to really repeat

yourself. You scale your team. And you

could potentially sell this skill

because now you understand how to set up

these frameworks with context management

and you know memory. And in this process

of building your own assistant, you're

going to get so much better at cloud

code, which is a really good skill to

have. So like I said, today I'm going to

be showing you guys exactly how I built

this thing. And there's four main

phases. So phase one is we need to give

it a home. So that's kind of like the

structure of our project, which I think

is the most difficult or kind of like

the most confusing thing up front

because as you guys saw in my project,

there's a lot of folders and in each of

these folders, there's a lot of

subfolders. So there's a lot going on.

So it's really important to be able to

make sure that you know where stuff is,

but that Claude also knows where

everything is because as you scale, more

and more files will be created, more and

more skills, more and more processes.

After we've given it a home, we need to

give it some life. So we need to give it

some rules. We need to give it some

context about you. It needs to learn

everything about you and what you're

currently up to. After that, we need to

give it hands. So we're going to build a

first skill together. And then we're

going to see how we can build more and

more skills and sub agents and stuff

like that so that it actually gets more

useful at doing things for you rather

than just like helping you think. And

then finally talking about how we

actually let this thing grow. How do we

improve it? How do we really scale it?

And how do we make sure that this

assistant actually gets smarter over

time and really is leverage for us. All

right, so phase one, let's give this

thing a home. So, if you guys have

watched any videos on my channel with

Cloud Code, then you've noticed I'm

using Visual Studio Code, which is just

an IDE, an integrated development

environment. It's completely free to

download for Windows or Mac. So, go

ahead and grab that. And then once

you're in there, this is what it should

look like when you open it up. Now, what

you have to do is come over to the lefth

hand side, click on extensions, and

you'll type in Claude Code, and it will

look like this. And all you have to do

is go ahead and install this. When you

do that, it'll prompt you to sign in

with your enthropic subscription, which

you do need to be on a paid plan for

Cloud Code. You could use your API key,

but it's better to just have a fixed

cost rather than worrying about how many

tokens you are racking up. All right, so

once Cloud Code has been installed,

you'll notice in the top right there's a

little orange button. If you click on

that, this is where you have the Cloud

Code actual agent that you can go ahead

and start talking to. But before we

start talking to it, we still haven't

really given it a home. So, we need to

set up a folder, which means you need to

open up your file explorer or your

Finder or whatever it's called, and

create a new folder. So, for this, I'm

just going to be in my desktop. I'm

creating a new folder, and I'm just

going to call this EA demo. EA for

executive assistant. And now, what I

have to do is open up that folder in

Visual Studio Code. So, I'm going to go

on the lefth hand side and click on the

explorer. And it says you have not yet

opened a folder. This will basically be

your project. And I'm going to go ahead

and click open folder and open that one

up that I just made. So, here is my EA

demo. Select folder. And now we are

actually in our project. This is the

home for our cloud code agent because

what I can do is open up this little

button. Close out of everything else.

And now we have our folder on the lefth

hand side. There's no files in there

yet. And then we have our cloud code

agent right here in the middle that we

can talk to. So now the second piece of

giving this a home is understanding how

cloud.md works and creating our cloud.

MD file. So if you've built an agent in

naden or you've built a custom GBT with

chat GBT, you understand that when you

do something like that, you have to give

it a system prompt. you have to give it

instructions. So that's exactly what we

need to do here and we do that with a

claw.md file. So the way that this works

is you send something to cloud code and

before it actually reads your message,

it's going to load in the claw.md file

and read the entire thing and it's going

to do that every single time. So the

claw.mmd file should have only the most

important rules about this is what the

project does, this is where you need to

look for your rules, this is where you

look for context, that kind of stuff.

because if you fill it super super full

of random information, then you're going

to go through your tokens and your

context window faster. So, what's

ultimately going to happen by the end of

this video is you will have not only a

cloudMD file, but you'll have acloud

file, you'll have projects, you'll have

context, you'll have decisions, you'll

have a bunch of different folders in

here. But the brain cloud.mmd tells

cloud code where does everything

actually live. So, that's how we stay

really organized. So, all we're going to

do in here to start is we are going to

come over to the lefth hand side. I'm

going to click on new file and I'm just

going to call it in all caps claude and

then MD. And MD just stands for

markdown. And so what happens is the

cloud.mmd file pops up right here. And

you can see that there's not currently

anything in there. So I'm just going to

say to claude, hey claude code, this

folder is for you to be my executive

assistant. So just throw a quick blurb

about that in the cloud.mmd file. I

shoot that off. It's basically going to

look through the project, see what's in

here, and then it's going to edit that

file so that we have a little blurb in

there. And unless you're on bypass

permissions mode, it's going to ask you

for permission here. So now it says

done. Cloud.mmd has a quick description

of your folder as an executive assistant

workspace. If I click into the cloud.md,

you can see this is what we've got. This

folder is cloud code's workspace for

acting as an executive assistant. Use it

to help the user with scheduling, task

management, research, drafting,

communications, and any other EA related

work they need. So this is going to

evolve throughout the video. You guys

will see that once we start to give it

some more life, which as you guys know

is phase two. So, like I said, cloud.mmd

is the brain, and it's going to tell

cloud code where to look for information

about us, which is going to be in a MI

file. Information about your business,

which will be in work, information about

your team, which will be in team, and

then information about what you're

currently focusing on right now, which

will be in priorities. And it will also

understand all of your rules, like the

way you like to speak, um, your style,

formatting, stuff like that. Okay. So,

I'm going to paste in this prompt, which

you guys will be able to access for free

in my free school community. I'll have a

post in there associated with this video

and then you just need to basically grab

that markdown file, copy it and paste it

into here. You can see that this prompt

is pretty beefy and it's going to

basically walk you through and have

Claude Code extract all the information

out of you that it needs to get this

project started. So, I'm going to shoot

this off and we're going to see that

it's going to start to ask us some

questions about us. So, phase one is

creating the folder structure and it's

initializing a git repo. And now you can

see that all of these folders and files

have popped up on the lefth hand side

which is very similar to how my Herk 2

project was set up. We've got templates,

references, projects, decisions,

context, archives, and the claude. So

all of this stuff is going to start to

get filled up a little bit. And trust

me, as you start to use this, it will

make much more sense. So now we are on

phase two, which is the interview

section. So first part, what is your

name? What's your role? What's your time

zone? Blah blah blah. So I'm just going

to give it some dummy information here.

Okay, so I shot off my initial answers

and now it's asking us more about our

business and our work. So, obviously I

am just kind of giving it some dummy

information to show you guys how it's

going to set up these folders, but this

is where you should really take some

time here and let it get to know you and

give it as much detail as you want

because ultimately you're going to want

it to know all of this stuff either way.

So, take your time here. Really give it

information. If it asks you something

and you don't know the answer to it,

maybe just say that you don't know and

see if it can help you brainstorm some

stuff. But also, you could just say

skip, you know, I'll set this up later.

And you can see that it might not move

on to the next section until it feels

like it has enough information. So,

right here, it asks if I had anyone key.

I said yes, I have one other person and

I didn't say the name. So, it's asking

what is the name? And now it's moving on

to priorities, goals, and projects.

Remember that you'll be able to plug it

in real time into ClickUp or, you know,

ASA or notion or whatever you use for

your project management and your goals

because a big part of this is making

sure that everything it's looking at is

actually current. This is just kind of

the initial onboarding to get it

familiar with your business. Section

five asks about communication

preferences. So, how do you actually

like to interact with something? because

this can be really flavored to you. And

remember, none of this stuff is

permanent. You can always change it

later. And the last section is what do

you want help with? So like what are the

recurring tasks that eat up your time?

What would you hand off to an assistant

first if you could? Are there any

specific workflows that you want to

automate or templatize? Now, if you

don't know right now, that's fine. Just

say skip because what's going to happen

is I'm going to challenge you to use

this as much as you can. Don't use your

custom GBTs. Don't use your projects.

Try to migrate everything into here and

just use this. And over time, you'll

realize what is recurring and what are

processes that you can actually use in

cloud code. So I just told it let's skip

that for now and let's just keep on

moving through the setup. So now that it

has all of our information, it's going

to build out the files based on our

answers. And we're going to be able to

see that right now it's writing the MI

file and now it's writing the work file

and now it's writing the team file and

the current priorities. And all of this

is going to get looped back together.

All right, so all of this is set up. We

have our tree view of our folder

structure. So we can really dig into

this if we want to see what's in the

cloud or what is in the archives, the

context, all this kind of stuff. We get

a summary of how everything works. So if

you're confused about any of this stuff,

you will get a summary and you can also

ask, hey, like what does this context

file do or what does the archives folder

do? And it will be able to explain it

for you. But you can see it's populated

this stuff with information about me.

The skills that we need to build are on

the backlog. Otherwise, if you listed

some, it would say, okay, cool. Let's

just start building those skills right

now. And as far as keeping the assistant

sharp weekly, nothing required right

now. We have auto memory for daily

learnings. Monthly, we'll update this

stuff. Quarterly, we'll update this

stuff. And as needed, we will log

decisions in the decision log. And pro

tip, if you want your assistant to

remember something permanently, just

tell it remember that I always prefer X.

And it will save that across all future

conversations. And then the last thing

it's going to do is an initial git

commit. And this is just local. It's not

going to do a actual GitHub repository

out on the cloud. So, this will just

kind of locally store these files so

that you can have some version control.

But if you want to, you could just say,

"Hey, instead of doing this here, let's

actually just do it on GitHub." And then

you would just give it your email. It

would be able to help you sign in. And

then it can actually just make the repo

for you, and it can handle all of those

future commits and pushes. So the

benefits of that is that in GitHub, it

basically stores all these folders, all

these files, which means from any

device, you could basically pull in that

repo into cloud code and you could

always have your executive assistant

ready. You've got cloud backups, you've

got rollbacks, you've got collaboration,

and you've got branching. So it's just

best practice to put your codebased

projects into GitHub. So let's just real

quick take a look at what actually

happened. So the first thing I want to

look at is the dotcloud. You can see in

here right now we have rules with

communication style. So if I open up

this, we can see that it threw in some

information about the way that we like

to talk. So bullet points, everything

concise, no m dashes, internal speak

casual, external speak even more casual.

If we go to the skills, we can see

there's nothing currently in there.

There's nothing in the archives folder.

In the context folder, we have current

priorities. This is everything that I

just talked about during our setup. It

also says when this was last updated,

which is nice. We've got our goals and

milestones, which it says update this

file at the start of each quarter. So,

that's good. We've got 2026 annual goal,

Q1 2026, Q2 2026, informal milestones.

We've got the MI file, which is going to

evolve a lot over time. You can even

give it information about your

background, where you grew up, all this

kind of stuff, and it can use all of

that to tailor it even more. We've got

the team markdown, so anything that you

needed to know about some of the key

people in your organization. And then

we've got the work MD, which has some

business and company information. In the

decisions folder, we have a log. So,

anything major that happens, it will be

logged here with the date, the decision,

the reasoning, and the context. We've

got our projects, which it created a

folder for each of them. So, we've got

chocolate pistachio flavor, we've got

website launch, we've got West Coast

expansion, we've got winter events. And

each of these have a readme file which

basically is just a quick description of

what this project actually means and you

know the status or any other information

about it. We've got a references folder

where we'll be able to drop examples and

SOPs. There's nothing in there yet. And

then for templates we also have you know

we're able [snorts] to drop in some

stuff that it can reference and this is

just an example session summary. Nothing

is in there for this session yet. And

then the last thing to look at here

would be the claw.md file. So earlier it

was just like a few lines and it was

very basic but now it's tailored towards

us. So, you are Jack's executive

assistant. Be direct, concise, and

casual. Here is Jack's top priority.

Here is what's very urgent. This needs

to happen ASAP. And so, this is getting

read every time so that it can basically

keep checking in. Hey, is this done? Is

this done? Now, here's something really

cool where the clawmd file can point to

the right files. So, remember how I said

that this got loaded in every single

time you talk to cloud code? That means

if we threw all of our business

information, all of the information

about you, your priorities, that would

be a lot of tokens. So remember that all

claw.mmd has to do is tell cloud code,

hey, if you need some information about

the current focuses, go read this file.

So that's exactly what you're seeing

right here. It says, hey, if you want to

understand who Jack is, go read this. If

you want to understand, you know, the

business details, go read this. And so

on and so forth. So that's how we're

able to save tokens here, but still give

Cloud Code all the information that it

needs. It will also tell Cloud Code what

tools it has access to and how to use

them. Right now, we haven't really set

anything up. And similar concept over

here with our projects. It says, "Hey,

if you want to look at this project, go

here. This project, go here." You'll

notice right now we're at about 87

lines, which is pretty good. I always

try to keep them, you know, under about

150, maybe 200 max. That's just best

practice. Over time, they're going to

get larger and larger, so you should

regularly be kind of compacting them

down and pointing out to other files

when possible. Now, this is a great

place to start, but at some point,

you're going to want to add some more

files on your own. So, this is what

you've got right now, but what you can

see is in my Herk 2 version, I've got a

few more. And one of the ones that I

added that you'll probably want to add

is a brand assets. So in here I've got

fonts and I've also got some images,

logos, brand guidelines, things like

that. So all you do if you wanted to add

a new folder or new files is you would

just come in here, add a new folder,

name it whatever you want, and then just

start a conversation with cloud code and

say, "Hey, I added a folder called

brand- assets. Just update your skill

documents or update the cloud.MD to know

that it's there. And what I'm going to

drop in there are logos or head shot or

things like that." So all of that can be

obviously customized as long as claw.md

understands that. So that's basically

the way that our project is set up. It's

now got a home. It's got some life. And

let's move on to phase three, which is

giving it hands. Actually letting it do

something for us. Okay. So if I was you

guys right now setting up this executive

assistant, the first skill that I'd

probably build is connecting it to

ClickUp or Notion or wherever you have

your actual like project management or

task management. And I'm not going to

walk through that right now because I

use ClickUp and I don't want to go

through that setup in front of you guys

because it might not apply to you

specifically if you don't use ClickUp.

But basically, it's super easy. You

explain in natural language exactly what

you want to do. You have it do research

on the endpoints or maybe even an MCP

server. And then all you have to do is

go grab an API key and put it in av

file, which you'll notice right here we

don't currently yet have. So here's what

you would do. I'm going to go to plan

mode and I'm going to say, "Help me

build a research skill. This skill is

going to use perplexity. So I need to

give you my API key in AENV file. So go

ahead and create that file for me. And

what I want the skill to do is help me

do research. This is more than just a

simple couple, you know, web searches

and web fetches that you might be able

to do already. This is research that's

kind of deeper and it's also tailored

towards me and my business because it

understands the context of, you know,

what's going on and our current projects

and priorities. So I'm going to shoot

that off in plan mode. Cloud code's

going to think about it. It might do a

little bit of research to help us build

this plan and then it's going to come

back with something. And what's pretty

cool is you can see that first of all it

explores the project to see how things

work and it even spun up a sub agent to

explore the structure of our project

right here. And sub aents are really

cool because they have their own context

window and they might even be able to

use their own model if you you know

configure one to do so. So I'll touch on

that a little bit more after we build

the skill. So I may come back and ask

you some questions which is a good

thing. So here it says for perplexity

what model do you want to use? And I'm

just going to go with sonar for now and

submit that off. And now it thinks it's

good and it's come back with a plan. And

we can see we have build research skill

with perplexity. Jack wants a reusable

research skill that goes beyond basic

web search. It's going to create thev

for our API key. Now the reason why it

needs to do that is because if you do

end up pushing this to a GitHub repo or

putting that anywhere on the web, it's

best practice to have. Eenv, which is

where you have all of your API keys, and

you don't give it to Claude in the

conversation history right here. It's

going to build the actual skill itself.

So we'll see that once it's created. And

the skill instructs Claude to understand

the question, load context. So read

through me, work, team, current

priorities, goals, and anything else.

Formulate queries, call perplexity API,

synthesize, save report, and then

present the summary. Another thing worth

noting is that it's also going to update

the claw.md so that it now knows about

this skill and knows that it exists. So

anyways, it looked at the API

documentation. It gave us a research

report format. I'm just going to go

ahead and auto accept this plan, and

it's going to start building it out for

us. All right. So, the agent just

finished up. It said, "Here's what we

created. We have thev, which you can go

drop your API key in. We've created the

research skill." So, if I go to Claude,

if I open up the skills, we can see we

have a research folder. And in here, we

have a skill.md for research. So, I'm

not going to read this whole thing, but

you can see now that we have this actual

skill. And as you can see, this

basically just says when do you use the

skill and how do you actually run the

process of, you know, calling the API

and making the report for Jack. And it

updated the claw. MD to show Claude that

this skill now exists. So, I'm going to

go ahead and grab my API key from

Perplexity and paste it into the ENV. As

you can see, I'm just going to drop it

in right here and then save it. Okay, I

put the API key in there and we're going

to test it out. I said research ice

cream events in Portland using the new

research skill. And what we're looking

for here is seeing if it's actually able

to call the skill. So, it says, okay,

let me load the relevant project context

and then I'll run the research. The

content has been loaded. Now I'm going

to break this up and I'm going to call

perplexity. So here you can see it did

three different searches. It searched

for Portland ice cream dessert events

and then it searched for Portland vendor

application process and finally it

searched for Portland dessert scene and

connections. So it comes back with a

very concise output which is exactly

what we told it in the way that we like

to communicate. We got this information

right but then it also says that I saved

the full report to this folder. So, if I

go to research, which it created a new

folder right here, we can see that we

have March 3rd Portland ice cream events

research. And this is a markdown file

that has much more detail about what it

actually found as far as these different

events and these different, you know,

vendor things that we might be

interested in. And it includes all of

the links to all the sources that it

actually pulled here. And what's great

about this and why you guys can probably

now see that the folder management is so

important because every time you do

research, every time you generate

content, every time you make updates to

projects, all of that still lives in

this project, which is why it gets

smarter and smarter about what you're

doing the more you use it because I

could basically clear out this context

and I could pick up right where I left

off because it's able to go read this

file, this research report. So, that was

a quick preview of a skill. Now, there

are going to be some times where you

might actually want to use a sub agent

instead of a skill. Now, as you guys

just saw in the demo, when you're

talking to the agent and you call a

skill, it basically just uses the skill

right here in this context window with

this model with that, you know,

conversation awareness. But a sub agent

basically gets called on by this main

worker here and it has fresh memory,

fresh context, and you can even use a

different model. So sometimes if you

want to do research, but you want it to

be cheaper, you could just tell it to

delegate that to a sub agent and that

researcher sub agent could maybe use

haiku instead of opus 4.6. So that's

kind of the benefit of a sub aent.

So, let me just show you guys real quick

how that would actually work. I'm going

to go back into plan mode and I'm going

to say I need to create that research

skill. So, basically everything you just

did with the research skill, but I want

to create that as a sub agent and I want

this to be using haiku instead of opus

just in case I need to do some cheaper

research. So, create that sub agent for

me. Put that within theclaw folder in a

folder called agents. So we now have the

plan to create that research sub aent

and you can see that it's going to use

model equals highq and I'm just going to

go ahead and accept these changes. So

what it did is it created the agent.mmd

which we'll go ahead and take a look at

and I believe that it also updated the

research skill so that if I say that I

want it to be like cheaper or to use a

sub aent that the research skill will

actually invoke the sub aent which is

pretty cool. And then it also added an

update to the cloud.MD file which now

should have an agent section. You can

see there's been a new folder created.

We have agents under our do.claude and

in here we have a research agent. So if

I open this up, you will see that we

have you are a research agent for ice

cream Fridays. You receive a research

query, call the perplexity API and save

a structured report. So I'm trying to

keep this as simple as possible, but

there is something that I want you guys

to notice about both the agent and the

skill that was just created here. So

these were created as complete markdown

files which is fine. But actually the

way that we need to set up both of these

is using a YAML front matter because

that's where we can actually have the

configuration. So I'm not going to dive

super deep right now into exactly why

this is but at a high level it makes

cloud code better at understanding what

that skiller agent does when to use it

and it's going to save you tokens as

well. So for now I'm going to manually

build this YAML front matter by

literally just going like this going

back into RS code and then for the skill

I'm just going to paste that up here and

then change the name and change the

description myself and I'm going to do

the exact same thing then with the

agent. But what I would actually

recommend you do is in your project give

cloud code this document. You know give

it the example give it even the URL and

say hey look up on this page what is the

best practice for creating sub aent

files or creating skill files so that

every time you build me a new sub aent

or you build me a new skill it does it

in the best practice. So really the

reason I showed you guys this and the

point I'm trying to make here is cloud

code is smart but it's way smarter if

you let it do its own research and then

save that research so that in the future

everything gets better and better. So

now you can see I've updated both the

agent and the skill with the YAML front

matter and now it's going to work a lot

better. It would still work the other

way but trust me this is just going to

save you tokens and you're probably

going to get more consistent results.

All right so now let's go ahead and test

that out. I'm going to go ahead and

clear this conversation and I'm going to

say I need you to do some really quick

research for me. I want to keep this one

cheap, so just use the research agent

and find out, you know, how ice cream

events are going in Los Angeles. All

right, so this is pretty cool. It read

through the research skill. It read

through the research agent. And then it

also read through my plans. So it said,

"Hey, Jack wants quick, cheap research

about LA. This ties directly into the

West Coast expansion priority." So now

it has all that context. It calls the

research agent with the model Haiku. And

now it's going to go ahead and do that

research for us. All right, awesome.

That research is done. If I open up the

research folder, you can see that right

here we've got our LA report about some

ice cream stuff. So, just keep in mind

the research report is still really

good. It still has lots of sources. It

still has lots of detail. It wasn't the

research that was worse. It was just

when all of that raw data got passed

back to Claude Code. It was using Haiku

to summarize it and to write this MD

file rather than having Opus do that.

Okay, so we've set up our executive

assistant. We have given it information

about us and our business. We have

connected it with a skill and an agent.

And now phase four is basically just

about letting it grow. Now I could walk

through some more step-by-step examples

with you guys, but really this is about

customizing it for your tech stack,

your, you know, project management

system, your team, and the way that you

work. So with my cloud code assistant

here, because I have all these different

agents now and these different rules and

these different skills, it's just

because I used this every day instead of

using like Claude or Chatbt on the web.

It gets smarter and smarter over time.

So right now you're at day one and if

you use this every day, a month from

now, this thing is going to look crazy

different. there's going to be way more

docs, way more decisions, way more

skills, and it's just going to be

smarter and smarter, and you're going to

be like living in that thing. So,

really, what I would challenge you to do

from here is to only use this. Just like

for the next week, try only using this.

Take all of your cloud projects, take

all of your custom GBTs or, you know,

your gems, whatever it is, take those

instructions, put them into this

project, and say, "Hey, turn this into a

skill for me." Use that skill, use new

skills, and every time that you're using

the skill, say, "Hey, this is what I

didn't like. This is what I did like.

Update it. you know, let's let's just

keep making it better and better. And

that same exact theory applies to the

entire system, the cloud files, the

reference files, the project files,

everything. And then, like we talked

about earlier, put this thing on GitHub,

have version control, and make sure that

if you switch to a different laptop for

some reason, you can still use your

executive assistant. But anyways, that's

all I got for this one. Now, I'm sure

you guys are all excited to keep

building on top of this executive

assistant. So, what's next is really

just to go master skills.

All right, this is where it starts to

get like really really fun. We're about

to dive into skills, sub aents, agent

teams, and a few other things. But this

is where we get so so powerful with our

Claude code setups.

I have genuinely never been as

productive as I am right now because of

Claude skills. This image really does

sum it up. I feel like I'm working on

multiple different computers and

multiple different tasks at the same

time without sacrificing quality. It

just comes down to one simple word and

that is leverage. with Claude skills or

any agent skills for that matter, you

have way more leverage than if you were

doing this by yourself. So, in this

video, I'm going to be breaking down

what skills are, how they work, and how

you can build really, really good ones,

even if you've never heard of the

concept or built a single skill ever

before. So, let's hop into a live demo

real quick and get going. All right, so

here we are in Claude Code in my Herk 2

project, which is kind of just like my

personal assistant. Now, if this stuff

over here looks overwhelming, don't

worry about that right now. Just worry

on what I'm actually asking the agent to

do. So, I've got this skill that I

called morning coffee that helps me plan

my day every morning. So, it's not

morning right now, but I'm going to run

this so you can see how it works. So, as

Cloud Code's figuring that out, what I'm

going to do is open up another agent.

And in this one, I'm asking it to run a

pulse check on all my projects and

commitments to see how things are going.

I'm opening up another one to create me

an Excal diagram of the difference

between local AI models and closed

source models. And let's just do one

more that's going to scrape the comments

from my recent YouTube videos and give

me an analysis on what I need to

improve. So, what you're looking at

right now is four different agents

running in parallel doing things for me.

And that took me probably 30 seconds to

ask them to do that. And because I built

all of these skills, all of these agents

have all of the context about my

business, what's going on with our

projects, my YouTube channel. It has

literally everything it needs. And now

all of those agents are done. Here was

my February 26th morning coffee. I had

three things on the calendar. So, what

it's going to do is it's going to look

at my ClickUp. It's going to see what

else I've got this week and look at my

tasks and then help me plan the rest of

my day. So, this is the plan that it

suggested. All I'd have to do is say,

"Yep," and it would block off everything

for me. And for me, that's huge because

I don't have decision fatigue anymore of

what I have to work on. The second agent

came back with a pulse check, 2 days

until the end of the month. Here's where

everything stands. So, obviously, I'm

going to blur all of this out, but it's

basically catching me up on all of the

different main initiatives that we're

doing this month and this quarter and

making sure that everything is on track.

And right here, you can see there's a

few things that I need to follow up on

manually. And this might have slipped

through the cracks because I'm so busy

making YouTube videos if I didn't have

this personal assistant to check up on

me using the skill. The third agent came

back and has finished the excal job

diagram and I pasted it in and it looks

like this. So if I needed to make a

video about this, I wouldn't have had to

take my own time to create this

visualization. So for the comment

analysis that came back and we can see

all of the comments, all the views and

things that I need to address either in

future videos or in the comments. We got

some confusion. We've got some cost

things that I need to cover. We have to

stop demoing toy examples for tool

videos. Seems like you guys really want

to see some anti-gravity stuff. I

promise that'll come soon. And then

we've got top three priorities. So, I've

been recording now this video for about

6 minutes. Just think about if I would

have done all four of those things

myself, how much context switching I

would have done and how long that would

have taken me. Okay, so now that you

guys have seen an actual demo and

hopefully you're a little bit excited to

learn about cloud skills if you haven't

used them yet, what actually are they?

So, skills are reusable instructions.

You write them once, you save them as a

skill. You can trigger them anytime, and

you're going to get way more consistent

results because it's going through that

same process every time. So this visual

right here was actually an AI generated

image that I used with a skill. It was

this one right here in my cloud code

called Excalaw visuals. But sometimes

with AI generated images, they don't

spell words right. As you can see here,

this is all messed up. This stuff is

messed up. So I also have one, as you

saw in the demo, to create Excal

diagrams. And this one creates the

actual Excal that I could move and edit.

And the words are always perfect because

it's actually just typing. And those two

skills alone have saved me so much time.

And what I'm going to do, by the way,

for all you guys, is in my free school

community, the link for this is down in

the description, I've added a new

classroom section called agent skills,

where I'm just going to be dropping a

ton of these skills that you guys can go

grab for completely free. So, before we

dive into this today, just real quick,

why should you care? And there's three

big reasons. You can be way more

productive as a person because you can

automate things like you just saw me do,

and you can legitimately build a

personal assistant that can do almost

anything for you. The second one is team

leverage. So, you can turn existing SOPs

into automations really, really easy.

And if you build something new, not just

you can use it, but your entire

organization can. So, everyone as a

group is getting way more productive,

which will almost undoubtedly result in

growth of the business. And also

monetization. We're entering this new

world where skills are having a big

moment and you're able to capitalize on

a lot of this stuff. Now, I'm not saying

this is going to be a viable business

model for a long, long time. So, you

shouldn't bank on it, but it is

something to be aware of just like when

people were selling edit workflow

templates and things like that. But once

again, it just comes down to one word,

which is leverage. This isn't just

theory. This is something that we're

seeing with clients. This is something

that we're seeing internally in my own

business. This speed of work that we're

able to achieve right now feels insane.

But that is going to become normal. And

if you can't do that, you instantly

become way too slow and way too

expensive for the business. And they

might not keep you around. We're

actually making it a priority to make

sure all of our employees are using

cloud code. Because now I have all these

different skills that I can just run

with a simple slash command or a simple

natural language prompt and get in one

day a week's worth of output. Because

once again, one person can figure out

the best way to do something and turn it

into a skill that the entire team can

use. But they don't just generate text.

They're basically automations. They can

run scripts. They can call APIs. They

can create things. They can have sub

agents. And they can be called on from

agents as well. So this is truly AI

automation. And just to really hammer it

home, they're basically SOPs for your AI

agents. The same way where you would

train a human employee by letting them

read through an SOP to understand the

process and then they'd be able to do

it, you just train an agent on it. You

give them the skill, they read it, and

then they do it. And the coolest part

about it is the more you use the skill,

the better and better it gets. So, we've

talked about a lot of these benefits,

right? But what actually is a skill?

Well, it's just a folder and it lives

somewhere in your project. The most

common example is probably going to be

in your do.claude/skills/skill

name and then you've got like a skill MD

or a markdown file. So, right here in my

Herk 2 project, you can see up top we've

got.claude. I open up.claude, we have

agents, rules, and skills. Right now,

we're just talking about skills. If I

open that up, we can see all the

different skills that I've created in.

So let's say for example the Excal

diagram skill. If I click into that, we

have a skill.md. And when I open that

up, you can see we have the name of the

skill, the description, and then we have

the actual workflow. Step one,

understand the concept. Step two, plan

the layout. Step three, generate

elements. And this entire skill

basically teaches my agent how to build

these Excal diagrams for me. So like I

said, that is the anatomy of the skill.

We've got front matter which is kind of

between these two dotted lines and that

is in something called YAML which you

don't need to worry about what that

means. This is just the way that it's

kind of indicated sort of like your

markdown or your JSON or Python. Now up

here we'll have a name and a description

which tells Claude Code what the skill

is called and what the skill does. So as

you can see this one is called Excalraw-

Diagram and there's a brief description

about what it actually does or when to

use it. And then we have the

step-by-step rules, which are basically

the instructions. And this is what

Claude actually does once it decides

that this is the right skill for the

job. Now, the interesting thing about

skills is that sometimes you need way

more data. So, for example, let's say

we're writing a LinkedIn post. We have a

skill for that, right? But what needs to

go in the skill is other information

sometimes like a company tone of voice

or maybe your LinkedIn, you know, tone

of voice, a target avatar, current

priorities, a logo. Maybe there are

other things that you want to put into a

skill besides just like the step-by-step

instructions that will make it better.

So, the question is, where do these

things go? Well, there's typically two

options, but essentially, as long as

you're pointing to the right path in the

skill.md, you're fine. So, let me

explain what I mean by that, and then

I'll show you what I mean by that. So,

first option is to have it

self-contained. So, in

yourcloud/skills/skll

name, you can have the skill. MD, you

can have your scripts right there, and

you can have your references right

there. Or option B is that they're not

directly nested right under that skill.

So here we have.claude/skill/infographic

and the skillmd and we still have our

scripts and our references in the same

project but it's just not nested

directly under that skill. And so I know

that might have made no sense. So let me

show you exactly what I mean by that.

Okay. So here we have a skill called

idea mining. And so what happens in here

is basically use when someone asks for

content ideas, video ideas, what to make

next or to run idea mining. And so in

here I gave it some context, right? My

channel has this many subs. It's about

AI automation. My content pillars are

naden, rag agents, cloud code, voice AI.

And then what I gave it is a bunch of

references. I gave it channel data,

which is YouTube channel.md. I also gave

it the raw data, which is a JSON file. I

gave it a competitor list for me. And I

gave it an actual script to run analysis

on my YouTube channel. And so in this

case, what you can see is that I went

for option B where I'm storing those

reference files and those scripts not

directly nested in this skill. So

basically what it could look like is

within the skill itself, we could have a

folder called, you know, references. We

could also have a folder in here called

scripts. And then within both of these

subfolders, we could have more things

like, you know, in the references, I

could have channel data. And in the

scripts, I could have

YouTube-analysis.js

js or py whatever it is. Basically the

idea is it doesn't matter where those

actual reference files or scripts live

as long as you point to the right spot

in the md file. So in my case where

these actually live is in a different

folder. So here for the channel data I

would basically just go all the way down

to references and then I could go down

to right here YouTube channel.md. So

cloud code reads the skill and then it's

able to find this if it needs it. Same

thing for the scripts. It would go down

here to scripts and then it would find

analyze YouTube. py and it would just

pull this in if it needed it. So

hopefully you guys are with me. However

you want to set it up works. And I think

that's the most overwhelming thing about

cloud code right now is that everyone

uses different kind of folder

architecture. But don't worry guys, I'm

totally on top of this. I have a skill

that I built out called skilluer. And

this one I'll be giving away for free

once again in my free school community

right here. And all you'd have to do is

load in the skill builder and then it'll

help you build out everything you need.

And I'll be showing a live demo of that

in a few minutes here. So the skill.md

is the actual brain itself and the

supporting files are the tools that it

can use. That doesn't mean every single

time the skill is invoked that those

reference files will all be called. And

just in case you guys were wondering if

you've watched some of my previous cloud

code videos where we've used the WAT

framework to build automations. This is

very very very similar in that

framework. The W the workflows were the

markdown file SOPs. That's basically the

skill. The tools were the actual Python

scripts and that's basically just the

scripts that you might write or the

references that you would add in. So, if

you've already been building some WAT

stuff, you will pick up skills super

super quickly. And the cool thing about

skills is that you don't have to build

all of them. Obviously, as you're

working with cloud code and you're

finding that you're doing things

repetitively, you can go ahead and build

a skill for it. But there's an official

library from Anthropic of Skills.

There's a community of everyone that's

open sourcing their skills and giving

them out. And there's a marketplace

where you can share and sell or you know

download skills from people. And then

you would take that skill or that

essentially a prompt and you would add

your own flavor to it. The one thing I

would say is just be careful and make

sure that no one's trying to, you know,

give you a skill that has any malicious

intent in there. And all these skills

can work across different products. So,

cursor, anti-gravity, codeex, because

it's so based in Markdown and it's

essentially just a prompt, tons of

different AI models can use them. Okay.

So, how does Claude know when to use a

skill? Well, there are two ways to

actually trigger them. The first one is

you can be explicit, which basically

means you can do a slash command and say

the skill name and it will just directly

fire off that skill. Or it could just be

natural language. So if I had a school

post skill, I could say

slashschool-post.

Or I could natural language just say,

"Hey, help me write a school post about

X." Claude would find that skill and

then invoke it. So when you ask Claude

to do something, it will first read

through the cloud.MD file. It will

analyze your request and it will search

through the skills and see which one do

I have that helps with this query. If it

finds one, it will invoke it. But if it

can't find anything, then it will

basically just use its general

knowledge. So not every single request

that you give to cloud code will invoke

a skill. Now a really important part of

that is understanding how skills stay

lightweight because if you've been using

cloud code you know that context

management is a huge deal. And if you

had all of these skills to look through

and all of these skills are I don't know

hundreds and hundreds of lines then if

cloud code was searching through all of

these every single time that would

surely eat up a ton of your tokens. So

what's used is something called

progressive context loading which

basically means we have three levels.

Level one is the initial search where

cloud code only looks for the name and

the description. So right here you can

see let's say we ask for an Excal

diagram. It would basically search

through all the skills but it would only

read the YAML front matter. So it would

read the name and the description. And

typically this front matter is only

going to be you know maybe roughly 100

tokens. So it stays very lightweight.

And then moving down to level two let's

say it identifies okay cool this is the

right skill for the job. Then it would

run the full skill.mmd and it would read

through everything. And so that's when

it would start to actually understand

what goes on in the skill. And that

might be anywhere from a thousand to a

couple thousand tokens. And then level

three is once again a decision. Only

load in the extra files when needed. So

if I need to look at any scripts or

references or templates or I need to

pull in some brand assets or more

context, I'm only going to do that if

the specific requests requires it. And

so hopefully now you're starting to

understand a little bit more about under

the hood what's actually going on when

you ask cla code to do something for

you. And you can always go to cloud code

docs and go to the skills section and

just read about how this stuff works.

It's really, really simple. On the doc

itself, it will tell you just make sure

to keep the skill.md under 500 lines.

Move detailed reference material to

separate files. And so, I know this may

seem like it's just a lot of information

being thrown at you. So, let me just

kind of contextualize this and slow it

down and reassure you guys. You're never

ever ever going to write a perfect skill

the first try. The way that I build my

skills is I have Claude Code do

something with me. I walk it through the

steps, you know, each time. And then

when we're done, if we've went from

point A to point B, I say, "Cool. This

is something I do once a day. Let's turn

this into a skill. Ask me more questions

so we can make sure you have all the

information you need." And once again,

I'm going to show you guys opening up a

brand new project and setting up a skill

from scratch so you understand the full

process, but I just had to give you guys

some context first. Now, we have this

thing called the feedback cycle, which

basically means you invoke the skill,

you actually watch the agent work, you

give feedback, and then it fixes the

skill, and then you do it again. And so,

the first couple times you run a skill,

you may feel like, eh, this feels very

AI generated. But by the time you've run

that skill 10, 20, 30 times, every

single time it gets better. And so,

that's why it's actually important to

watch the agent work the first couple of

times because that's how you're able to

identify opportunities to speed it up

and save tokens by doing things like

this. So here's an example of the pulse

check skill that we actually ran

earlier. Now this skill gets invoked

when I ask for a pulse check or checking

in on commitments. And what it does is

it reads through some context of how

OTAAS work, which is important for it to

understand every single time it reads

the skill, which is why I put it here

rather than a reference file. And what

it has to do is it has to do a live

lookup on my ClickUp to understand

what's going on. So what I did is I

hardcoded in these list IDs because when

I was watching it, I realized every

single time it was doing this, it was

calling the ClickUp MCP and it was

gathering all these lists and it was

searching and parsing the results and

then it would extract the ID and that

just was taking so long and it was

costing me a ton of tokens. So I

realized that's always going to be the

same. Why don't I just give it in the

skill document the list IDs and now it

knows how to do that instantly every

time and it doesn't waste all those

tokens. And on top of that, I know that

searching through ClickUp can consume a

lot of time and tokens. So, I built a

specialized sub agent that in this

skill, I say, "Hey, delegate to the

ClickUp searcher agent with this query

in order to do all of this searching so

that you don't blow your own context

window." All of that's handled over

there and then you only get the

information that you need. So, there's a

lot of advanced things that you can do

to manage your context. I'm not going to

dive into all of that right now. We're

just focusing on skills, but just wanted

to give you a little taste of what's

possible in the skill.md files. So,

another good example of needing a

reference doc like that is in my skill

builder skill. I obviously use this when

I'm creating new skills, optimizing

skills, auditing skill quality, things

like that. And a lot of the inspiration

I got from this was of course straight

from claude code docs itself about how

to actually use and build and optimize

skills. And so, when I was building this

out, I I was watching the agent, you

know, run the skill and I realized it's

searching every single time. It's doing

a web search and it's crawling the

entire document, even if I just need a

little piece of information. So, what I

decided to do was I told it to basically

scrape that whole thing and then I gave

it a reference.md, which is basically

the documentation. So, I've got my

skill.md and what it does is it

references that full file if it needs

it. But really, the main idea that I'm

trying to drive home here is that

processing markdown files for your agent

is so much quicker and cheaper than

actually making API calls or HTTP

requests, you know, executing functions

and reading tons and tons of tokens. So,

the goal is your skills will get to a

place where you can invoke them, focus

on something else for 10, 15 minutes or

whatever, and then come back and have a

finished result that is really, really

good. But the first couple times that

you are testing out a skill, I think

it's a really good idea to just sit

there and watch it and see what it's

doing. And a lot of people have asked me

like when do you know when to build a

skill? Well, basically just go about

your work and if you ever realize that

you've done something already or you've

instructed something differently, like I

tell my claude to not use m dashes.

Okay, well that's probably a good idea

to put that in the prompt, right? So if

you ever find yourself doing a process

or repeating prompts, then that's

probably a good use case to build a

skill around it because skills don't

have to be complex. They could literally

just be a 50line markdown file. All

right, so we're about to hop into a live

build of a skill from scratch. But what

I wanted to do real quick was go over

the six-step skill building framework.

So number one is the name and the

trigger. What is it called and the

natural language that would basically

fire it off? Number two is the goal. So

in one sentence, what will this skill

accomplish by the end? What will be the

output? Number three is the actual meat

of it. That's the step-by-step process.

If you had to do something manually,

exactly what do you do in what order?

What do you look at? And what decisions

do you make? Number four is the

reference files. What context do you

need? Do you need images? Do you need

understanding of current projects,

current priorities? Do you need style

guides? What do you need to do the job

well? Number five is the rules. Think

about what could go wrong and then the

agent can help you building guardrails

and constraints around that. And then

number six is kind of like after you've

built it, it's just the self-improvement

loop. And after the live build, I'm

going to talk about actually testing and

iterating and what you need to do to

make them really, really good. But for

now, that's the sixstep skill building

framework. Let's hop into a live build.

Okay, so here we are in Visual Studio

Code, which is where I like to use Cloud

Code. If you don't have Visual Studio

Code, just go ahead to a browser, type

in VS Code, and then go ahead and

download this. This is what it will look

like. If it's your first time using

Cloud Code in here, you just have to go

to extensions on this lefth hand side,

type in Cloud Code, and then install

this, and then log in with your paid

Anthropic subscription. Now, after that,

you're going to click on this top left

button, and it's going to pull up this

little thing that says you have not yet

opened a folder. What you need to do is

open up a project to work in. So, you

could either open up one that you're

already working on or you could go ahead

and create a new folder and then open

that one up. For the sake of the demo, I

just opened up a new blank folder called

a bunch of skills. And I'm going to show

you exactly what to do. So, the first

step is to go to my free school

community link in the description. Go to

the agent skills classroom and download

the skill builder folder. Once you've

got those files ready to go, first thing

we want to do is just set up this

workspace real quick. Initialize this

project with a simple.cloud/skills

structure. Cool. So, as you can see,

that got set up. We have aclaude. We

have a skills folder. And what I'm going

to do is in this skill folder, I'm going

to create a new folder called

skill-builder

and hit enter. And then I'm going to

take those two files for my school

community, the reference and the

markdown. And I'm going to put that

right in here. So now we have this skill

builder set up with the reference file

and the actual skill markdown. I'm

asking it if it can see that new skill

that I just added. It says yes, I can

see it. And I'm basically just going to

say, cool. Let's run that skill to build

a new one together. So now you can see

what it did is it basically is reading

the skill right now. This is the

instructions that we saw right in here.

As you guys know, since that's how

skills work, it starts to read this. So

here we go. I built this skill to

actually ask you questions so that it's

way easier for you to communicate what

you want. So the first thing is what

problem are you trying to solve? What we

want to do is content creation because

in this skill, what I want to do is

building branded infographics. What kind

of content does the skill create? What's

the specific use case or workflow? And

I'm actually just going to choose other

for this. And I'm going to say

educational infographics. Now it's

asking how we should trigger this skill.

So does it want to be natural language

or do we want to just use slash

commands? And I'm just going to say both

is fine. And now we're moving on to the

step-by-step process, which is really

important because at this point we

haven't told it what text stack we

actually want to use or anything else

about our business. So walk me through

what should happen from trigger to

output. And it has some good guesses.

But what I'm going to do is do other and

explain this the way that I want it

built. I will tell you what I want an

infographic about. You will create a

concept. You will make a request to

key.ai to use nanobanana to generate the

outline or sorry to generate the image.

And you will also look at the brand

guidelines that I give you so that

everything that is created follows my

brand colors and typography and stuff

like that. The output format that I

actually want is a PNG, not any of this

stuff. Does this need to be

conversational or fire and forget? I'm

just going to go fire and forget. All

right. All right. So, how does the key

AI nanobanana integration work? Is it an

API call? Yep, we're just going to go

with an API call. And in these options,

you could literally say, I don't know.

Let's try different things. You know,

help me figure out what's best. It's

asking where those brand assets live, so

I'll put them in a folder. And where

should the generated PNG infographic be

saved? Yeah, sure. Let's start a new

folder called projects, and we'll throw

all of them there. So, it's going to

keep our project organized as well. So,

now it's asking about brand guidelines.

I created this folder, and I put in our

kind of color scheme as well as the

actual AIS logo. I have put in both our

AIS brand guidelines and the AIS logo. I

want to make sure that in the top left

corner of every single infographic

that's created, the AIS logo appears

exactly as I've given you. But I think

you guys get the point here. I'm going

to answer a few more questions and then

I'll just show you when we have a

result. And now that we've done that,

what you can see is it is going to

create the skill. It's going to create

the logo overlay. It's going to create a

supporting reference markdown file for

all of the API details that it's going

to need. So that's great. It's going to

register the skill in claw.md and it's

going to log its decisions. All right,

so it fully built the skill. It created

all those files for us. We just have to

give it a key API key so it can actually

run this. Okay, so I threw in my API key

and then I said test it out with an

infographic about cloud skills. That's

it. No other context. It invoked the

skill right here and we will see what

happens. Okay, this is really

interesting. So what it's doing is it is

generating the image and then it's just

going to overlay the logo. So, it's

gonna be a lot more consistent than

giving the AI image generator nano

banana my logo. So, I didn't even tell

it to do that. Let's see how it looks.

Okay. Well, I don't love this. We're

just going to go back and ask it to

change some things. The logo on the top

left doesn't look great. I gave you a

logo with a transparent background, so

it should just be overlaid on top and we

should be able to see the background

behind it. The actual infographic itself

is all right, but I actually want these

to always be one by one aspect ratio.

Okay, so I made some suggestions and

it's going to try again and it's going

to update its skill. So we'll see if

that's better. All right, so second time

we run the skill. Let's see if it's any

better. All right, there we go. We've

got the logo up top. We've got cloud

code skills, custom AI workflow, command

prompt, trigger, front matter, config

triggers, AI agent delegation, document

output. So just keep in mind all we said

was build an infographic about cloud

skills. And this was run number two.

Every single time that we do this cycle,

remember we talked about the feedback.

We would basically watch it again, give

more feedback, and then keep going. And

after we run this probably five or six

more times, this would be really, really

good. And then every time I ask for an

infographic, it's going to be

consistent. And just to show you guys

what was actually built, if we open up

the infographic builder skill, we have

the actual skill itself. So we have the

front matter right here, the name, the

description, we've got what the skill

does, we've got context, so here's where

it links to the actual brand guidelines

and logos. We've got the step-by-step

workflow right here. And we can see

right here for full API reference and

parameters just see the markdown file so

that you don't have to actually go

search the web and search through a

bunch of tokens. You can just read this

markdown file. All right. So we've

talked about a lot of stuff about skills

today and we just built one live. So

what I want to talk about now is really

how do you bridge the gap from like a

90% good skill to making it pretty much

100%. So testing, iterating, and

debugging. There's different symptoms

and there's different fixes. So let's

just kind of go down this list one by

one. The first symptom might be it does

the wrong steps or in the wrong order.

Well, you would just tell it to edit the

skill.md instructions. You could get

missing tone, style, or context. In that

case, you're going to add reference

files. And of course, those have to be

pointed to correctly in the skill.md.

You could get the same mistake happening

over and over, then you're going to add

a rule. If it struggles with a tool or

an MCP or it keeps searching for the

same things, then create some sort of

reference dock for it. If it works good,

but it could get better, then that just

means you have to brute force it. you

have to just run it over and over and

over and keep nitpicking at what it does

wrong or maybe not wrong but what it

could improve on. If the skill isn't

triggering, then check the YAML and make

sure it is specific enough. If the skill

triggers too often, then maybe try

disabling model invocation and that is

something that you can see in the claw

docs, which basically gives you control

over if the skill can only be invoked by

natural language or only be invoked by

the slash command directly or both. So,

like I said, if you want to look at some

more advanced stuff, then definitely

head over here to the actual doc. But at

this point, we've covered almost

everything about these skills. One thing

that I would call your attention to is

the actual front matter reference

because we saw the name and the

description which is what's required

every time. But there's lots of other

things that you can add in there. Here

is the disable model invocation like we

just saw. But you can also give it

allowed tools. You can also give it an

argument hint. You can give it a

specific model to use. You can give it

specific context. You can give it hooks.

You can give it a specific agent. And so

all of this lets you get really really

granular on the exact skill and how you

want it to be used. But don't get

overwhelmed. You really only get to that

point once you've ran the skill a ton of

times. Now, another thing that I need to

hit on real quick is where do skills

actually live because what we've seen so

far is just building them right in

ourcloud/skills folder. But when you're

doing this, they only exist in that

specific project. So whether that's my

her two or my, you know, the one we just

spun up, if I went to a different

folder, that skill would no longer be

able to be accessed by our cloud code.

But you can also create skills that are

actually global. And you do that by

doing that in a different directory in

your kind of overall home directory. And

that's basically indicated by the little

tilda right here. And so that means

every project you use in cloud code, no

matter where you are, that skill would

exist. So for example, I have a

front-end design skill that is installed

globally. So that whenever I'm anywhere,

if I need to do front-end design, it

just is able to use it. And just in case

you want to look at it in a different

way, right now what we're doing is we

have our projects, right? So, herk 2 and

then we have doclaude and then within

dotcloud we have skills and then your

skill and then your MD your references

whatever and then maybe another skill.

But if it was global you might not

actually see it in your project. It

would just be within your overall home

directory. So the reason why you might

want to do this is if there's something

very specific about you, your business,

your workflows that you want applied to

every single project no matter what.

Maybe your company context, your company

projects, your tone of voice, whatever,

then you can install that globally

instead. If you guys love nerding out

about this kind of stuff, then

definitely check out my paid community.

The link for that is also down in the

description. We've got a great

community, over 3,000 members in here

who are building with AI every day and

building businesses with AI. So, I'd

love to see you guys in this community.

Cloud skills just got 10 times easier to

build and stronger to use. So, in

today's video, I'm going to explain

exactly why that is, and then I'm going

to live build a completely new skill

right here in front of you guys. So,

real quick, what is a skill? It's

basically just a recipe. So that when

you ask your agent to make you, for

example, a LinkedIn post, it will read

the recipe and it will get it right

every single time. And when I say

recipes, I literally just mean text.

It's just text instructions. It's like a

prompt. So if I go to customize and I go

to skills and I click on, let's say, for

example, the internal comm skill, this

says a set of resources to help me write

all kinds of internal communication

using the format that my company likes

to use. And you can see this is the

skill itself. It is literally just text

that you could read, that an intern

could read, anybody could read and

understand what's going on in the skill.

And if you're using them in cloud code,

you can see I've got a ton of skills

here. So, for example, let's look at my

um idea mining skill. This is the

markdown file that explains to the agent

what this skill actually does. And once

again, it's all just text. So, what did

Enthropic actually do that made all

these skills better? they updated their

skill creator skill which is literally a

skill that teaches Claude how to build,

test, measure, refine, just make all the

skills better and better and better. So,

let's actually cover why that matters

and what happened. So, the first thing I

need you to understand is that there are

two different types of skills. We have a

capability uplift skill, which basically

is a prompt. So, it teaches Claude how

to do something better. for example,

design websites with the front-end

design skill or create documents or run

Excel formulas. Things that maybe the

default model by itself doesn't know

super well, but with a prompt, it does a

much better job. And then we also have

encoded preference skills, which means

that Claude already understands each of

these pieces, but it needs to follow

them in a specific order. So these are

way more like actual workflows, like

actual kind of like step-by-step

automations. So, quick example. If you

ask Claude without a front-end design

skill to build you a website, it could

do it, but it might just look very

generic. It might look AI slop as they

call it. But if you give it the exact

same prompt, but this time you also let

it use the front-end design skill, it's

going to look much better because that

skill tells it stuff like good fonts,

good color schemes, you know, good

background elements, good layouts. And

that is a classic capability uplift

skill. Now, here's an example of an

encoded preference skill, which is the

one we just saw in My Cloud Code, which

I call idea mining. And this skill is a

little bit more sequential and there's

different steps involved. So, first it

will look at my YouTube comments. It

will look at, you know, some videos in

my niche. It will also look at AI trends

on X and the web. It will then spin up

two different agents. So, a YouTube

agent that analyzes this stuff and a

research agent that analyzes this stuff.

And these run in parallel. And then they

both send their output back to the main

agent, which will score and cross

reference. And then the main agent turns

all that information into some video

ideas for me, which is why I call it

idea mining. So, what I could do is I

could say, "Hey, Mr. AI agent, go look

at my comments, go look at YouTube, go

look at X, you know, analyze that and

help me find some video ideas and every

time it would give me different answers

and every time it would sort of do it

differently or I can just say, "Hey, do

some idea mining." And it will just call

the skill and every time I get an output

that I like. And the reason why this is

actually important to understand is

because capability uplift skills might

fade over time because for example with

the front-end design skill, right now

we're with Opus 4.6, right? What if Opus

5 drops and default Opus 5 is better at

front-end design than Opus 5 with a

front-end skill? So, at that point, you

might just need to retire that skill

completely. But with an encoded

preference skill, these will probably

stay pretty durable and accurate because

the process is very specific usually to

you, which Opus 5 won't be trained on

most likely. Okay, so those are the two

kind of different types of skills. Now,

we can actually evaluate them. So, with

this new skill creator skill, which is

an official anthropic skill, this is the

one we're talking about. It's in the

repo right here. And if I open up the

actual skill MD, you can see this is

what it does. It creates new skills. It

can modify and improve existing skills.

It can measure skill performance. So use

this when you want to create a skill

from scratch, if you want to update or

optimize one. If you want to run evals

to test a skill, if you want to do

benchmarks, or if you want to optimize a

skills description for better trigger

accuracy. So I'm going to talk about

what each of these little elements mean,

but I just wanted to show you that this

is the actual skill creator skill. It's

basically just all of Enthropic's best

practices on how to build better skills.

They've done things before like dropped

a 33page PDF which walks you through

fundamentals, planning and design,

testing and iteration, distribution and

sharing, all this kind of stuff,

patterns and troubleshooting. This is

pretty thorough. So you could either

take time and learn this or you could

just give your agent the skill creator

skill and all that information is

already in there. So what the eval do is

it lets your agent actually evaluate the

quality of your skill and then make

improvements. So, let's say you have a

skill for creating job descriptions.

What you could do is give your agent

tons of examples of really good job

descriptions that you want. And then it

will look at your skill. It will test

out some prompts and it will compare it

to the outputs and it will be able to

optimize your skill for you. As we've

talked about in the past, the more you

use a skill, the better and better

because you're able to give feedback on

what you like and what you don't. So,

this basically shortcuts that process.

Here's a quick example that Enthropic

actually ran with this eval. The skill

for filling out some PDF stuff was

having trouble finding the right spot to

put the text. But then after they ran

the evaluation on the skill and it was

able to improve, now you can see all the

text is accurately being placed whether

that is a checkbox or just a fill in

some sort of field. So there's two

reasons that we need to use evals and

they sound kind of similar but they're

basically the opposite. So the first one

is to catch regressions. So this means

let's say we have a job description

skill. As a model evolves it might

actually use the skill worse because

it's trained a little different and it

you know thinks a little different. So

this would basically be an early signal

that you need to evolve your skill. And

then the second one is to spot out

growth. So once again, as models improve

or evolve, it might be able to just do a

better job without a skill at all. And

that's when you would be able to run the

evaluation, say, okay, wow, without a

skill, it's actually better. And I'm

just going to go ahead and delete this

or maybe just archive it. And then we

can also run benchmarks. So when a model

updates or when you make an iteration

and you change your skill, just run all

the evals and run a benchmark which will

give you stuff like a pass rate, a time

and also how many tokens are being used.

So here's an example where they said

benchmark the PDF skill with and without

the skill loaded and show me sideby-side

results so I can see the uplift. And we

get all this information about these

different evaluation metrics. We get the

pass rate, we get the total time and the

total tokens. So here you can clearly

see that with the skill you're getting

much better results. And then the final

piece is skill trigger tuning. So once

you've got a project filled up with,

let's just say 10 or more skills, you

might notice sometimes that you get

false triggers or you get misfires,

meaning you wanted it to use a skill and

it used the wrong one or you wanted it

to use a skill and it just didn't use

any at all. Luckily, you could also use

them with slash commands, but it's so

much more convenient to just be able to

speak a natural language and make sure

that your agent understands you. So

using the trigger tuning, the skill

creator will basically analyze your

skill. It will test out different

prompts that you might use to trigger

that skill and then it will edit the

description so that that skill gets

called more accurately. And this is an

actual evaluation that they ran. You can

see on the lefth hand side and on the

right hand side we have the test score

and the train score. And the green and

blue are basically the results after it

has been analyzed and fixed with the

trigger tuning. So you can see it's

still not perfect, but it's so much

better than where we were without this

new skill. And what I think is really

cool and how I want to end off this

section before we get into a live demo

is where this is going. And at the

bottom, we have a quote from Enthropic

themselves that say, "Over time, a

natural language description of what the

skill should do may be enough with the

model figuring out the rest." And I

really think that this word may should

actually have been will. And basically

what this means is that today when we're

telling our agent to build skills for us

or maybe just giving it an SOP, we're

giving it steps, rules, and format. But

what's going to happen in the future is

we're going to be able to just tell it

in way more highle natural language what

we want and it's going to be able to

figure out all of that and get there

with a spec and basically just cut down

the time that it takes for us to get a

really good skill or you know a really

good automation. All right, so I am in

my Herk 2 project which is kind of just

like my personal assistant in cloud code

and I'm going to show you guys how we

can actually get the skill installed. So

whether you're in VS Code, which is

where I am, or in the terminal or

desktop app, whatever, you just need to

do /plugins, you can click on manage

plugins, and then if you just go in here

and you can see like all of the kind of

anthropic official ones, you can just go

ahead and search for skill-creator.

And right here, you can see the official

one. Here's the GitHub. And all you have

to do is go ahead and click install. You

can install this for just you, you can

install it for your project, or you can

install it locally. And I'm just going

to install it for the whole project.

So now you can see that's installed and

I'm just going to go ahead and restart

Claude Code so that that actually

happens. And so just keep in mind if

you're in Cloud Code, it may not show up

right here in your actualcloud skills if

you did it, you know, in your project.

So you can just verify it and say, do

you have the skill creator skill? What

does it do? And you can see right here

that we do in fact have that. So I'm

going to go ahead and switch on to plan

mode and I'm going to see if it can

build us a new skill. I need you to

create a skill called YouTube weekly

roundup where at the end of every week,

you will look at the videos that I made

that week. You'll analyze the comments,

you'll analyze the views, engagement,

things like that. And you'll give me a

PDF report on all of the insights,

strengths, weaknesses, threats,

opportunities. So, that's all I'm going

to send off. And I kept this pretty

vague intentionally to see what it's

going to come back with and how it's

going to be able to plan this out for

us. And this is where the future's

going. And this is what Enthropic is

talking about because most people that

are using skills right now are actual

just like executives and managers and

operators. They're not engineers, which

means we're really good at being able to

explain what we want, the metrics we

need to hit, and why we need that, but

maybe not all of those technical

nitty-gritty details. All right, so it

came back and asked me some questions.

The first thing I said is I want it to

just be the last 7 days. So, it's a

rolling 7-day window. It asked about the

report sections that it came up with,

and I said those look good. And for the

PDF style, I told it to use the brand

assets in my folder. So right over here

I've got my brand guidelines and then

this one is the actual logo for AIS. So

I'm telling it to use those and

hopefully it can throw all that on there

and make it feel really branded. So it's

going to keep going now with this plan.

All right. So at this point it came back

with a plan. And keep in mind I still

haven't told it anything about text

stack or anything else. It's writing out

everything that it's going to do. And

normally I would read through this and

give it some tweaks potentially but I

just want to see what this skill creator

is able to do with a oneshot prompt. And

I'm just going to go ahead and accept.

And look at this. In its to-do list we

can see that it creates all these

things. But then the last step is to run

the test and iterate with the skill

creator eval process. So I'm excited to

see what it does there. So you can see

that it created everything and then what

it did is it decided to test it to do a

final iteration. Okay. So I was a little

confused. I said, "Do you have an actual

PDF file for me?" And it said, "Yes, it

is in your projects folder." I was

looking in the templates where it

created an HTML template, but apparently

it actually rendered that as a PDF. So

let me go to projects. We'll go to

YouTube weekly roundup. And right here

we have an actual PDF, which this

doesn't look great. Obviously, this is

not a PDF, but if I actually open it up

from my files, it is a PDF. So, here we

have the logo, we have weekly roundup,

we have three videos published, and then

we got some stats on views, likes, and

comments. I'm going to keep going down.

We have our executive summary. So, this

is for it actually ran I think two weeks

worth of data just to test this out. And

I will say just by glancing at this, I

don't think that this data is correct.

So, keep that in mind. Here we can see

the per video breakdown. Right now, we

have nothing available in our SWAT

analysis. And then we have competitor

context and there's nothing available

here. So now it's time to give it some

feedback and see what it can do. I'm

first of all going to clear out this

context because it used up 62%. I'm

going to go back into plan mode and just

give it some honest feedback. All right,

so the report looks great. Like

aesthetically, you did a good job on the

design. However, the data is all wrong.

There was a lot of missing elements. I

need you to really look at how you're

actually scraping this data from my

YouTube channel, how you're actually

searching through the comments and

competitor videos and make sure that

there's actually data going into this

report. And before I send this off, it's

interesting because you can see here it

sent us some JSON data, which is

actually the raw information that it was

able to find from my YouTube channel.

And the thing is, this isn't super

in-depth. So, I just don't think that it

did a good enough job on the research

element. And maybe this is exactly what

we were talking about earlier over here

where at some point the AI is going to

be able to understand that we want all

of this granular data, but maybe right

now it's our job to just explain that

really clearly. I want to see comments

analysis. I want to see what's working

for other people in the space. I want to

see, you know, other trending videos in

AI. And I want you to use all of that

and use your brain to figure out what

are the strengths my channel has, the

weaknesses, and the opportunities and

the threats. And then all of this

information should be a pretty in-depth

research report for me on, you know, my

YouTube weekly roundup. So, while this

is running, I thought that we should

real quick look at what it actually did.

So, in my claude, we've got my skills

folder. If I go all the way down, we've

got the YouTube weekly roundup. And this

is the MD file. So, we've got the YAML

up top with the name, description,

disable, model invocation false, which

just basically means that Cloud Code can

call this based on a request. It doesn't

have to be explicitly a slash command.

And then an argument hint. So basically

when cloud code decides to use this

skill, it will send in maybe a hint so

that the skill understands like what

video we're looking at or you know the

topic. It's giving some context. It's

giving some channel benchmarks, some

optional focus and then step-by-step

instructions on what to actually do

here. Now you can see what it's doing is

it's calling on a script called fetch

YouTube data, which if I was to look for

that in here, I could probably go down

to my scripts. I could see YouTube

weekly roundup. And right here we've got

some different things. We've got the

prepare data. We've got the render

report. And we also have a script that I

already had in this project that it was

able to find and use, so it didn't have

to create a new one. And this one is

called fetch YouTube data. So the

skill.md file here basically points to

everything that the agent needs in order

to do this accurately. Okay, so it's

come back with another detailed plan,

and I'm going to go ahead and fire this

off. And I love this. Once again, we've

got all these to-dos, and then at the

end, it says to audit with the skill

creator. And this is such a good example

of why using a project more and using a

skill more makes it stronger because

some of the pieces that I already had in

this project, it's able to reuse like my

YouTube analyzer agent, like my YouTube

data script. And of course, it has all

the context about my business and my

YouTube channel in here already. So all

of those changes have been made and now

all that's left to do is actually run

the skill. So I just called the skill.

You can see that it's reading it right

here. And now what [clears throat] it's

doing is it's going to refresh channel

data. It's going to use three agents in

parallel, prepare the report, populate

the data, and then render the PDF and

show it to me. So, I'll check in with

you guys when we get that output. All

right, that finished up. We've got some

quick hits. Top competitor move, biggest

opportunity. Apparently, Jack Roberts is

my biggest threat. If you see this,

Jack, keep crushing it. Okay, so here is

the report. These stats right off the

jump look a little bit more accurate. I

might want to tell it to make this logo

a bit bigger, but it did what we asked.

Seven videos published, and like I said,

these stats look more accurate. We've

got the executive summary here with some

key takeaways of doubling down on dollar

outcome titles, make a dedicated

anti-gravity tutorial, fill the chat GBT

to claude migration, watch Jack Roberts

closely, and then address VS Code versus

anti-gravity confusion. We've got the

per video breakdown. So now you can see

the actual metrics from all the videos,

including the one that I literally just

dropped like an hour ago. And so all of

these look like they're doing okay. This

one might not be doing the best, and

similar with this one. But I really like

the way that this actually looks. The

layout's pretty good. It is very clean

and professional. For the SWAT analysis,

we actually have it on the second page.

It still looks good. That's obviously

just an easy spacing issue that we can

fix. So, we have some strengths here. We

have some weaknesses. We have threats.

And we have our opportunities. Top

comments and audience signals. Selling

shovels in a gold rush, bro. Well

played, man. 26 likes. Hi, Nate. 10 days

into joining your plus community. I got

my first potential client. It's all

thanks to you and your community.

Awesome. And you can see that we see

other comments. We see what video they

came from and how many likes. And we're

also getting video requests, we're

getting pain points. And so that really

helps me stay in tune with what you guys

are saying. Wow, it just keeps on going.

We've got competitor context. So all of

these channels, all of these videos, all

of these stats, and that comes along

with some notable gaps. And then

finally, we get what's trending in AI

this week. So what are skills, the most

powerful AI agent I've ever used, all of

this stuff with the channel, the views,

the views per day, and the topic. So

this is amazing. And I was able to build

this in 20 minutes. And now what I would

do is just keep running it. And every

time say, "Hey, I liked this. I didn't

like this. Use the skill creator to make

this better and better.

So, here I am in Cloud Code and I'm

going to go ahead and shoot off this

message that's asking Cloud Code to turn

my YouTube video into a tweet style

carousel. What you see is that it's

invoking the carousel skill. And within

this carousel skill, I actually tell it

to delegate work to a carousel planning

sub agent. So, you can see now it said,

"I got the transcript. Let me plan the

carousel slides." And I'm using an agent

to do that. And so this sub agent here

basically got the input from this main

session and it's running on its own with

its own context and maybe a different

model whether that be haiku sonnet or

opus. And while we let this finish up,

I'm going to open up a new session. And

in this one, I said spin up two research

sub aents. One for AI enablement for

SMBs and one for enterprises. And this

main session now is going to delegate to

two different sub aents. Here's the

first one for SMBs and here's the second

one for enterprises. These sub agents

are now running in parallel doing their

own research and then they're going to

send all of their findings back to this

main session. So in that first session,

we now have that carousel done. We've

got slide 1, slide 2, 3, 4, 5, 6, 7, and

8. And then in the second session, we

see that both research briefs are back.

We've got SMB AI enablement, we've got

enterprise, and then we have the

overlap. So these outputs that we just

got were thanks to using cloud code sub

aents. So in today's video, I'm going to

explain all of this as simply as I can,

and we're going to be looking at what

they are, why they matter. I'm going to

build one live in front of you guys,

talk about how we actually do that, and

how you can actually master them and

make them better and better. So I don't

want to waste any time. Let's get

straight into the video. Okay. So what

are sub aents? The idea about sub aents

is that you have your main session. So

as you guys saw in cloud code, this is

kind of the agent we're talking to. When

you open up a new session, you are

talking to this little crab right here.

And as you're talking, you fill up your

context and it has its own kind of

memory right there. But that main

session can actually delegate work and

send off prompts to different

specialized agents. So we could have a

code reviewer or a builder or a debugger

or a testr runner, an architect or a

researcher. And if we wanted, all six of

these could be running in parallel.

You're essentially turning clawed code

into a project lead. And it's able to

just do the planning, the delegation,

and then not have to have its context

polluted with different specialized

tasks. And the more specific goal you

give it and the more specific training

you give it, the outputs are shown to be

much much better. Especially if you

think about it like this, a sub agent

will be asleep, right? and it wakes up

and it's completely stateless because

basically the main agent said, "Hey,

wake up. I need you to do something."

This agent now wakes up with fresh

context, a different chat model, its own

tools, and its own purpose. So, it's

like if I was throwing a party and I

wanted some really good cupcakes. I

probably wouldn't just walk into a

general store and just grab, you know,

some mass-produced cupcakes, I might

want to go to like a niche bakery and

give them a custom request. Now, you

might have also heard of agent teams,

which kind of sounds similar to sub

agents, but they're not. And there's one

key distinction that I wanted you guys

to just understand real quick. Don't

worry, I will have a full video about

agent teams themselves, but I just

wanted to do one quick distinction,

which is that sub agents are focused

workers. They run in parallel, but they

can't talk to each other. And that's the

key difference. It's basically one-way

relationships. The main agent sends an

input prompt and then the worker works

and then sends the results back to the

main agent. The individual workers

basically cannot communicate. But with

agent teams, that's where it gets really

cool is they actually can. So they share

a task list and they can communicate to

each other. They can even assign each

other tasks. So that's where it truly

becomes like an actual team ecosystem.

So let's actually go through an example.

So let's say I said, "Hey, I need you to

refactor and add some tests to X, Y, and

Z." What the main session would do is it

would basically hear your request and it

would search through the agents it has

and say which ones can do the job best.

I'm going to give one task to the

refactor agent. I'm going to give the

other task to the test writer agent.

They're both going to be working and

then once they're done, they're going to

bring all of those results back to me,

the main agent, and I will do whatever I

need to do with it and communicate back

to you. Okay, so why use sub agents?

I've got five reasons here. And the

first one is to preserve context because

you can keep the main thread clean. We

all know that context rot is real and so

your job as a cloud code operator is to

figure out how can I be as efficient as

possible with my context window. And one

of those unlocks is realizing that you

can delegate tasks to sub agents to

process tons of data, do a ton of

research, and then only send back the

little bits of information that the main

session actually needs. Now, the second

piece is to enforce constraints because

maybe your main worker, your let's just

call it a parent worker needs to be able

to do tons and tons of different things

in terms of like tool calls. But

sometimes when you want to do something

a little bit more risky, so maybe GitHub

actions or some other code-based

actions, you might want to delegate that

to a sub agent that is specialized on

that tool or that process and it has

limited availability when it comes to

tools. So it can't do anything super

harmful. It just gives you more control

over that process. Now the third one is

to reuse configs. Meaning all of your

agents can be shared across different

projects or even shared with your team

because maybe your organization has a

really specific process for project

management or quarterly planning. And if

you have a really good agent that helps

you do that, then it can be reused

across the entire organization. So the

whole team gets better and better. And

what you'll notice is that there's a lot

of principles between sub agents and

skills that are very similar except for

like the context and model things. Now

number four is specialization. Kind of

like I alluded to earlier, the more

specific and niche an AI is trained to

be, the better it results are going to

be. And that's as simple as it is. If

you've been following my channel for a

while and you've been building a lot in

Naden, it's the same idea of when we

would delegate work to a child agent.

And then finally, we have control costs

because once again, each sub aent can do

their own model. So maybe you're always

wanting to use Opus in your parent

workflow, but sometimes you want some

quick research done and you can do that

with Haiku to save yourself time and

tokens. So from there, the big question

is when do you actually delegate?

Because you could also get into this

weird spot where you're doing sub agents

for everything and you're kind of just

overengineering. So stay in your main

conversation if you need back and forth,

if you need quick changes, if you need

that shared context, that conversation

history, and for low latency. And then

you want to be able to delegate to a sub

agent if you want them to be

self-contained, if you have tool

restrictions, or you just want summaries

returned. Now, I know I put verbos

output here, but that was just the image

generation. Basically, you can control

if you want to see the sub agents steps

as they're thinking and doing things, or

if you just want the concise summary

done at the end. So, I thought that I

would share this tweet with you guys

real quick. Boris Churnney, the guy who

created Claude Code, shared that he does

use a few sub agents very regularly.

Build validator, code architect, code

simplifier, on call guide, verify app.

And also, if you go to the cloud code

docs and you read about sub agents, you

can see that there are some examples

here which basically give you the full

actual like MD of this type of agent.

So, this is the code reviewer. And if

this doesn't make sense at all, don't

worry. I'm going to explain what we're

looking at here. We've got a debugger,

we've got a data scientist, and we've

got a database query validator. So those

are just some example sub aents you

might be thinking about and seeing just

to kind of get the you know blood

flowing up to the brain. So here's where

your understanding of skills is going to

help out a little bit because the agents

are basically invoked the same exact way

that skills are invoked which means that

the main agent will read through the

descriptions of the agents. So if I said

hey can you help me write tests for my

API? The agent would look through all of

its different agents. It would see I've

got a refactor, I've got deploy, I've

got a test writer and a debug and I'm

going to use the test writer here. And

then it would basically send off that

prompt to the test writer agent. So the

clearer that your descriptions are, the

better that the delegation is going to

be so that you don't get any false

triggers and things like that. And when

I say description, I literally just mean

the actual description. So for example,

the code reviewer agent expert code

review specialist proactively reviews

code for quality, security, and

maintainability. Use immediately after

writing or modifying code. So, like you

guys just saw, we have the YAML metadata

where we would have things like the name

of the agent, the description, tools,

and there are a few other um options

here, other parameters like model for

example, and then below it, we would

have the actual instructions that cloud

code would actually read the full list

of once it's decided, hey, Mr.

Testrunner agent, I'm going to use you.

So, literally same way that skills work,

and all they are really is just a

markdown file. So, I think understanding

that really simplifies the concept. And

very similar to skills once again

because it's just a file they live in

your project. So they can be either in

your project, they can be personal, or

they can be temporary. So personal means

if you create an agent, you can use it

anytime you're using cloud code

regardless of the project. But project

means that you would only have it in

that specific project. So for example,

in this project, this is my herk 2. So

basically my executive assistant and

I've got my do.cloud right here. In the

dotcloud, I've got agents. And here's

where I have my six agents right here.

And I can only invoke these if I'm in

this project. So if I switched open to a

different folder, I couldn't use those

agents. But if I installed them

globally, then I would be able to, but I

wouldn't actually see them right here.

I'd see them more in like my home global

directory for cloud code. And then

temporary agents, you can spin up ones

just for your session explicitly or with

certain plugins, but I've really never

used these before, so not going to cover

them today. Okay, so we're about to hop

in and build our own custom sub aent.

But I did want to show you guys that

there are some sub agents that cloud

code has natively built in that when

you're using cloud code you might have

actually seen before and you would know

if you're using a sub agent because it

would have this little command that says

agent. So the first one that we have is

explore and this one basically searches

and analyzes through your codebase. This

one runs on haiku and it has readonly

permissions. The second one that we have

is a planning agent. So a lot of times

when you're in plan mode you'll see that

this agent gets invoked and this one

does research and helps you plan. The

model for this one is inherited by the

parent model. So if you're on opus a lot

of times the sub aent will be running on

opus and this one's also read only and

then there is a general sub agent which

cloud code will invoke when we need some

multi-step stuff and this one once again

the model is inherited but this general

agent can use its hands a bit more and

it actually has all tools available.

Okay, so now that we understand all of

that let's go ahead and jump into cloud

code and build our first sub agent. All

right, I am in cloud code and I am using

cloud code in VS code. Now, what's

recommended by Enthropic to actually

build sub agents is to use the / aagents

command. So, if I come in here and I

type in slash agents, you can see that I

can click on this right here. And when I

click on that, it says that I have to

continue in my terminal to actually use

this. Part of the limitation with

extensions in IDE is that some of the

actual slash commands you can't use. But

it's not a big deal. You can just open

up the terminal. It will run the command

like that. You can see. And now we're

basically using cloud code in VS Code,

but in the terminal. And so once it's

ran the / agents command, you can see

that we can look at all of our agents.

So we have 11. We have the project

agents right here. And then we also have

the built-in agents that are always

available. And so I could choose these

agents and I could edit them or do

whatever I want. But what I can also do

now is I can click on create new agent.

So when I hit enter, this is basically

going to help us configure the agent and

it's going to understand all of the

different preferences even like where we

want to put this. So it's a lot more

helpful than you trying to build your

own. So for this demo, I'm going to go

ahead and do a project agent, but once

again, you could make them personal. I'm

going to generate with Claude instead of

doing it manually. And now all I have to

do is describe what this agent should do

and when it should be used and we need

to be comprehensive for the best

results. Okay, so I just kind of talked

into this thing for a little bit and got

a brief prompt. I would probably

recommend that you make these a little

bit more robust, but of course you can

always go back and forth later as you're

testing them and every time you use the

agent, it should be getting better and

better because you're going to give it

feedback. Now what I'm going to do is

I'm going to hit enter and it's

basically generating that agent from the

description. So, we're going to see that

it's going to fill out a new MD file

over here, and then we'll be able to

test it out. Now, what's cool about this

is not only is it just building the

agent from my description, but it also

is looking through what's in this

project. So, it understands me and my

business and my goals, and it's going to

actually make the agent a little bit

tailored towards that. So, this agent

that I described was like an AI trend

hunter finder, and it's going to

understand that I like have a YouTube

channel, and that I'm trying to make

content on like Nitn, Claude Code, stuff

like that. Now, the first option we get

is what tools do you want it to use? So,

I'm just going to go ahead and choose

all. But here's where you could go ahead

and say like I only want it to have

readonly and you know MCP. That's it.

But like I said, I'm just going to

choose all and continue. We also now get

to choose the model. So, I'm just going

to go ahead and go with sonnet. And then

you can choose a color for your sub

agent, which is pretty cool. You only

really see this in the terminal. So,

like let's say I'm in the terminal and I

say, "Hey, run the AI trend hunter." We

would see that this color I'm pointing

at my screen like you guys can see. we

would see that this color pops up and

that's how we know that that agent's

being used. We have the ability to

configure memory which I know I haven't

touched on yet. I will touch on that a

little bit later, but for now let's just

go ahead and do the recommended enable

option. And now what we get to do is we

get to see how the agent is configured.

So this is the name, this is the

location, tools, model, memory, and we

can see the description which tells

Cloud how to use the agent and then we

can see the system prompt. Now it did

make this description kind of long. So,

we might want to change that cuz that

might be using up too many tokens, but

that should probably guarantee that it

will get invoked at the right times. But

anyways, you can see you are an elite AI

trend hunter. Here is your mission.

Here's what you're looking for. It tells

it about how to use its memory and how

to update that and how to search for

past context, which is helpful for a

tool like trends because I don't need to

get an update on something that it told

me about, you know, like 2 hours ago.

And if you're getting an error that says

like it can't create it because that

folder already exists, then what I would

do is I would rename the current folder

that's called agents. So just call it

like agents one and then hit enter. It

should be able to create the agent. Move

all your agents into that new folder and

then just delete the old one. I think

that's just a bug. I've gotten that a

few times before, but it still works.

But then over here, you also notice that

we have agent memory. So right now we

have a folder for the AI trend hunter.

There's not a memory file in there yet.

But for example, our content hunter does

have a memory file and it will get

created after we run the AI trend hunter

one time. So what I'm going to do is I'm

just going to run the actual um AI trend

hunter agent in the terminal so you guys

can see what that color thing looks

like. Now what's interesting here is

I've already given it the API keys that

it needs in this project for like

perplexity or for X. But that's

something else that you will have to

configure if you're setting up an agent

for the first time. It needs to know

where to access those API keys if it's

calling some sort of API or doing other

tools like that. And as you can see, we

can see that the AI trend hunter is

firing off. We can see the web searches

and the different things that it's

doing. We have the ability to hit

control O if we want to expand and see

like everything that it's thinking and

doing. And right here, we can see the

prompts that the main workflow actually

fed into this sub agent, which is pretty

cool. And the other thing you'll notice

is that right here we could hit controlB

in order to run this agent in the

background which basically just means we

would be able to keep talking to the

main session while we wait for this

background agent to finish up just in

case we want to keep working and we

don't want to be blocked right now

because this is running in the

foreground. And by the way, the reason

this doesn't have a color is because I

chose no color. But I'll just check in

with you guys when the sub agent has

come back with a summary for us. All

right, so sub agent came back. We have

some hot signals. We've got some warm

signals. We've got top video ideas and a

key pattern. And so once again, the

value prop here is that the sub agent

used about 40,000 tokens, but the main

agent only had to actually eat up this

many tokens, which is nowhere near

40,000. If I run a quick context

command, we should be able to see that

this session right now has only used

29,000. So that just proves that the

main agent didn't have to look at all

those 40,000 tokens. Now, what else just

happened here is we can see that a new

file was created in the agent-memory,

which is the AI trend hunter. This is

the actual file that the sub aent is

going to read when it gets woken up. It

can see good sources to use. It can see

recurring topics. It can see patterns

and video angles that worked and also

the latest scan. So yes, it wakes

[clears throat] up on a completely fresh

set of conversation, but it also does

get some information to make it a little

bit more like recent. Okay, so that was

a quick live build of an agent. Now, we

used the / agents command to do so,

which lets us view agents, create new

agents, edit configs of agents, delete

them, and see agents that are active.

However, the one thing that's not great

is when we do the slash agents and we

want to like let's say for example edit

the AI trend hunter. If we choose edit,

it basically makes us open this in an

editor and edit the actual text file

itself. So, it doesn't really let us use

its AI brain in a really nice way to

optimize our sub aents. And there's so

many little nitty-gritty things that go

into how you use them and different

agent patterns and things like that. So,

what I did is I built you guys a skill

called agent builder which is trained on

pretty much the complete official docs

of cloud code sub aents. And so what

that would let us do is you can see

right here we have an agent builder. And

when I invoke this, it's going to help

me like run an audit on that agent that

we just built and see how we can

basically make it better. So this agent

builder skill can be found in my free

school community. The link is down in

the description. You would go to

classroom and then you'd come to agent

skills and you'd be able to download

that skill and just put it right into

your own project. So you can see after I

invoked it, it said, "Awesome. I've read

the AI trend hunter agent and I've ran

the audit. Here's what I found." So

there's no current tool restrictions. If

there's no max turn set and the

description is bloated, here are some

other things that would be nice to have.

And then here are some things that look

good. So then it says, "Hey, do you want

me to change these exact things?" And it

will actually help you brainstorm over

how to make your agent file much, much

better. All right, so now that you

understand that, let's talk about what

else actually goes into making our sub

agents really good. So the first thing

is auto delegation. And unfortunately, a

lot of these things just mean that you

have to use them a few times. And the

more you use it, the better you

understand how to improve it. So, you

want to be making sure that in your

natural language when you're explaining

like the goal that you're looking for,

it understands to delegate that to a sub

agent or maybe multiple sub agents.

Then, we have the idea of foreground

versus background. Kind of like I showed

you guys, foreground blocks the main

chat and the background lets them run

behind the scenes so you can keep

talking to the main session. And then

again, we have the strategy of taking a

huge amount of context and having the

sub agent process that rather than the

main agent. We have this idea of

composable skills and agents being able

to let them work together. So kind of

like that demo that you guys saw. So if

I hop back into cloud code, you guys

remember I used the carousel skill in

that demo. And in this MD, it basically

says gather the input and then you plan

the carousel. And you do this by

delegating to the carousel planner

agent. So anytime I invoke this skill,

the carousel planner agent gets called

on. And I've got another one where it

actually delegates to two different

agents. If I go to my idea mining and I

go to this skill MD, you can see that

the first agent we call is the YouTube

analyzer and then the second agent that

we call is the researcher agent. So once

again, this skill calls on different

agents. But what else you can do is you

can have agents invoke skills. So you'll

really start to see as you build up this

library of different skills and agents,

they can all sort of come together in a

really cool way. Tiny agents win. So

don't have one that plans and builds and

tests and documents and researches and

reviews. have one that does each of

those individual steps and then the main

session can just reconcile all of that.

Utilize parallel research. So maybe you

need to do some research on O, some on

database, some on APIs and then

synthesize all that. But just remember

they can't talk to each other while

they're doing their individual research

unless it's an agent team. And then kind

of like the way you can use them in

skills is you can chain them together.

So once you have a specific process, you

can say, "Hey, I need you to first use

the code reviewer agent and then the

optimizer agent and then this agent and

then that agent." And that basically

becomes an AI workflow where it's a

deterministic order of operations, but

some of the processes within are

non-deterministic. It gives us way more

control and that whole process is going

to get refined really well. And then

remember, start to optimize for cost and

speed. So rather than using Opus 4.6 for

every single thing you need to process,

every single sub agent, start to

understand how can I run these ones with

Haiku and these ones with Sonnet and see

if you can get, you know, parallel

agents running that are giving you way

more bang for your buck. So remember I

touched on the fact that agents can use

skills. You could just have them do that

in natural language because they can

view the whole project just the same way

that a main agent would. But you can

also preload those. So in the front

matter you can tell it specifically here

are two skills that you need to use. And

then you can also think about things

like sub agent compaction. So by default

I think it's around 95% when the sub

aents will compact. But you could also

change that autocompact to make it you

know 50% so that you avoid that context

rot. So now I think you guys understand

what I mean when I said there are so

many different things in this doc about

how to best use sub agents. Here are all

of the different supported front matter

fields. We've got name, description,

tools, disallowed tools, model,

permission mode, max turns, blah blah

blah. There's more and more. And so

that's why if you want to learn more

about sub aents and optimize your sub

agents, just use that skilluer skill

that I have given you guys. As you can

see, this is the markdown file for it.

And then I also gave it a reference MD

file which is basically even more

information about this documentation of

how to build sub aents. So this should

really help when you are doing this.

I just pasted in this message and I'm

shooting it off to Claude and it says

create a team called Neuroflow of three

teammates using Sonnet. The first one is

a front-end developer, the second one is

a back-end developer and the third one

is a QA agent. So this now invoked a

tool called team create. And you can see

that what it's doing is now that it's

created this team, it's spawning up

three teammates in parallel. And these

are all individual agents. So right now

we can see we have our front-end

developer, we have our back-end

developer, and we have our QA agent. So

what's happening is right now we have

these three agents working together with

our main session. They all share a task

list. They can talk to each other. And

I'm going to check back in with you guys

once this is done. Okay, so this is

really interesting. The front end and

backend developer sent work over to the

QA agent, and then the QA agent found

three critical issues. So, the main

agent said that it's going to send all

of this work right back to those first

two agents to take another pass at it.

So, here's where you can see it sent off

those messages to the front-end

developer, the backend dev, and the QA.

And now they're all back to work once

again. And there we go. The second time

the QA agent gives it a pass. All three

of those critical issues have been

resolved. And then it was able to

basically oneshot this website. Now,

obviously, there are some things that

aren't perfect about this, and we'd want

to go back and iterate, but considering

in the prompt, all I said was to build

me a landing page for a fictional AI

startup. And we get all of this text. We

get these animations. We get all of this

stuff to come in dynamically. And it

feels pretty polished. It came up with

all the copy, the color scheme, all of

it. This is truly one of the most

powerful AI agent features I've ever

used, but you have to know how to use

it, right? Which is why in today's

video, I'm going to explain everything

you need to know. What they are, how to

set them up, how to use them, when not

to use them, everything that you need.

So, let's not waste any time and get

straight into the video. So, agent

teams, as you guys saw in the demo, we

had one get spun up called Neuroflow.

And in that team, we had three agents.

We had the front-end dev, the backend

dev, and the QA. So, what happens is the

main orchestrator, the cloud code

session you're talking to, creates these

different agents and manages them, but

not in the same way that we do sub

agents because sub agents work

independently and then they send their

individual result back to the main

agent. Agent teams have a team lead,

maybe like a project manager, and it

creates all of these different agents

and a shared task list. So, the huge

unlock here is that individual teammates

can talk to each other. So, sometimes

there's a dependency. teammate one needs

something from teammate two and they can

just talk and you can get in these

really cool loops especially when you

have the QA agent like we just saw in

the demo where one of the teammates will

basically say hey this isn't good enough

and send the work back and then the main

agent like I said is just making sure

that the tasks are getting done and that

they're all high quality. So that's the

big difference between sub agents and

agent teams and I had to clear that up

because I know that's probably where

there's some confusion. So, I am going

to break more stuff down, but what I

wanted to do first is just show you guys

how to set this up because I think the

best way to learn is just to be able to

play around with stuff. And all you have

to do to set this up is add one

environment variable into your project

setting. So, let me show you how that

works right now. All right, here I am in

cloud code. I like to use it in VS Code,

but you can use the agent teams feature

wherever you decide to use cloud code.

You can see that I am in a brand new

project with nothing in it. So, this is

exactly what one of your guys' setup

should look like if you want to follow

along. So, like I said, we need to

enable the feature. And I'm going to do

that in this demo on the project level.

So, what I'm going to do is go to the

official Cloud Code documentation for

agent teams. And you can see right here

that it says they are disabled by

default because it's an experimental

feature. So, you have to enable them by

adding this variable into your

settings.json. So, what I'm going to do

is literally just copy this JSON right

here and come into Cloud Code and say,

"Hey, I need you to put this in our

local settings in this project." And

then just paste in that JSON prompt. And

I'm going to go ahead and shoot that

off. And that should basically be able

to create that file for us. So you can

see that it set everything up. We now

have acloud folder. If I click into

here, we have a settings.local.json

and it has put that command in there.

And now our project should be set up to

actually be able to use agent teams. Now

before we dive in and I start showing

you guys how to do that, there is one

thing that I recommend doing first. And

that's basically training your cloud

code project on how agent teams work so

that they can actually be used as

effectively as possible. So the easiest

way to do this is you go to the

documentation on agent teams. You take

the URL and you copy it. And then I

said, "Hey, create me a master reference

guide for agent teams in a folder called

docs. This will be used to help you

build better and more effective agents

in the future. And now it's going to

read through that documentation." And

now if you ever have questions about

agent teams or if it ever needs to look

up something while it is building them,

it already has that locally here stored

as markdown. So it's going to be much

quicker. And it just created this

documentation about enabling them, when

to use them, display modes, task

management, hooks, best practices, tons

of stuff like that. And that can be

found in the docs folder in this

section, which is a full markdown file

with hundreds of lines. And that's just

a little tip. That's something that I

like to do whenever I have like maybe a

big MCP server or certain documentation

that I know it might need to look at

constantly. So, now that we're pretty

much set up and ready to start building,

let's talk about prompting. How do we

actually tell Cloud Code to build us

agent teams, but not just to build them,

but to actually make them really good to

give you what you want? Because the

truth about agent teams is that they are

more expensive and they are a bit

slower. But you do get much higher

quality if you use them right. Now the

good news is you can pretty much invoke

them just using natural language. So I

kind of follow this pattern. Create a

team of X number of agents using X

model. So Hiku, Sonnet or Opus. And then

you basically just say the agents that

you want. You would say the first agent

is X ro this agent should be doing this

and it should produce me this. It can

talk to the other agents to do X Y and

Z. And so pretty much just listing that

out in natural language, whether that be

an API designer, a database engineer,

and or a test writer. So let's take a

real quick look at an example prompt. So

I'm going to read this full one out.

Now, what you'll notice is I start off

by establishing a goal. The reason I do

this is because when the agents wake up,

they have no context. They basically

only get the prompts that the main

session feeds into them. So if we tell

the main agent a goal to give to these

sub aents, they understand a little bit

better, you know, like what they're

working towards, but also why they have

their teammates next to them. So the

goal here is to build a working full

stack app with a REST API and a React

front end. The end result should be a

running app that I can view on a local

host. It should have users and post

functionality plus a QA test report

confirming that everything works. So

then I said, hey, create me a team of

three teammates using Sonnet. The first

one's a back-end dev. It should be doing

this. The second one is a front-end dev

and it should be doing this. And the

third one is a QA agent that should be

doing this. You can see that in the

descriptions I said when you're done

message the front-end dev. And then in

this one I said wait for the backend

dev's message and then you will send all

the stuff to the QA. And then I'm saying

what the final deliverables should be

because the main agent spins these three

up and then it's going to get a bunch of

information back. So what do I actually

want at the end of the day? I want a

running app. I want a report about pass

and fail tests. And then I want a doc

which is basically what was built, key

decisions, and how we run this moving

forward. So we're about to hop right

back into cloud code and live prompt an

agent. But real quick, let's talk about

some dos and don'ts. So do have each

agent own specific files because if you

don't do this and agents are sharing

files, they might overwrite each other's

work, which is not good. Do define the

output. Don't use vague deliverables. Do

name recipients. Don't just assume that

they're going to understand who to talk

to and why. Do have about three to five

teammates. Don't go for massive agent

swarms of 10 plus. That'll also be 10

times more expensive. And do give full

context because of the fact that no

history is given beforehand. Now, of

course, they can still read everything

in the project. They can still look

through all of those files, but no

context is fed in initially. And I will

show you exactly what I mean by that

when we go in here and spin up a new

agent team. Okay. So, I'm in that

project that we set up together. I'm in

a fresh session and I'm going to send

off this prompt. I said that the goal is

to help me clean up the workspace. We

have three agents called research team.

We're using Sonnet. We've got a

researcher, a strategist, and a critic.

And they're basically just going to read

through this project and make sure that

everything's accurate and make sure that

we're set up good. Let's take a look at

what's going on. It's creating the

research team, right? So, it's created

the team, and now we have a to-do list.

Now, what it's doing is it's going to

spawn the three teammates in parallel.

And when it spawns these, I'm going to

actually show you how. So, the first one

is a researcher. If I click into this,

you can see that this says in. So, this

is basically saying this is what the

main agent sent to the agent. you are

the researcher on the research team.

Here is what your job is and you have to

be thorough and include anything that

might be helpful. So this is basically

the prompt that spun up that agent. You

can see same exact thing happened for

the strategist and for the critic. And

if I clicked in, we could once again

read exactly what they were prompted to

do and the step-by-step instructions,

including stuff like when you're done,

send your five use cases to the critic

teammate using the send message tool,

which once again validates that these

agents are able to talk to each other

and send messages to each other. So now

we can see that all three of our agents

are running and they are all basically

just waiting for their turn. And you'll

notice what it does is pretty much every

time there's a new update, it updates

me. So here comes another live update.

Let's see if the researcher is finally

done. There we go. It's done. So now

what happens is we sent a message off to

the researcher. And let's go ahead and

see what that message actually said. So

this is the main agent talking to the

researcher. It said, "Did you send your

structured inventory to both the

strategist and the critic? Please make

sure the strategist also received it.

You were asked to message both

teammates. And then we can see that the

researcher confirmed that both teammates

received the inventory and now the

critic is running. All right, so

everything just finished up. All the

reports are here. But real quick, I

wanted to draw your attention to this.

The main agent said, "Cool. Let me shut

down the teammates and finalize." And

I'll touch on this a little bit later.

But now the main agent has sent a

message to each of them, the researcher,

the strategist, and the critic. And

basically said, "You're done. Save your

work." So anyways, we'll come back to

that in a little bit. But we now have an

output which is a new document over

here. Agent teams patterns and it found

a ton of stuff. There were 11

documentation gaps identified that are

worth reviewing against your reference

doc. So anyways, let's just click into

the doc real quick. We're not going to

read this whole thing cuz I'm assuming

it is super long. But this is the actual

output that we just got from this agent

team. And you can see that this thing is

insanely thorough. So if you wanted to

really really understand how agent teams

work, then spin up an agent team to help

you explain agent teams. Now, what

you'll notice here is we were kind of

able to see what was going on, but not

really under the hood. We couldn't

actually tell what the agents were

thinking or doing. And that's because

we're doing this in the Cloud Code

extension. If you do this in your

terminal, and specifically if you have

T-Mox installed, you can actually see

the different agents working and

thinking, and you can individually send

messages to them. Because right here,

we're kind of only communicating through

the main session, and the main session

sends messages to the other ones. But

one of the value props of agent teams is

that I could individually message a sub

agent if I wanted to. So, let me show

you what that looks like. All right, so

right now I'm running Cloud Code in a

T-m terminal. Now, if you're on Windows,

you have to take a little bit of a

workaround, but you just have to be in a

T-m terminal. So, I'm not going to do a

full setup video on it right now, but I

literally just had Cloud Code walk me

through it, and it was super simple. But

anyways, what I did here is I just

pasted in this prompt, which obviously

is like we talked about. We have the

goal. We say create me an agent team,

and then we have our front-end dev, our

backend dev, and our QA. This is

basically the same exact prompt that I

ran in the demo. So, this isn't to show

you the actual deliverable. What I want

to show you guys here is the way that we

can visually see this. So, right here,

what it's going to do is it's going to

spin up that agent team for us, right?

It's setting up the task dependencies

and it's assigning owners. And now it's

spawning those agents. And there we go.

We just got our front-end dev created

right here. And this is the blue agent.

We have another one right here, which is

the backend dev. And this is the green

agent. And there we go. We just got our

QA agent, which is the yellow one. So

now I very clearly can see what each of

these agents is doing, which is super

cool. And now if I wanted to, I could

come over here and I could check on the

team status with the main session. I

could come up here and I could talk to

the front-end dev. I could approve

things or I could give it more info.

Same exact thing with the QA or same

exact thing with the backend dev. So now

I literally have an agent team that I

can watch and I can interact with any of

them. And I can also watch them do

research, create things, talk to each

other. It's super super cool. So like I

said, I'm not going to run this whole

thing out. I just wanted to show you

guys that this is possible. Okay, now

that we've seen some cool demos, let's

talk about how do we actually make these

things better and better and understand

a little bit more about what's going on.

So, here are three key rules. The first

one is that each of these agents has

their own territory. So, they should

have their own file and they should be

working on their own deliverables. They

can send them across and they can

communicate, but they should only really

all be editing their own thing. The

second thing is once again direct

messaging. They can talk to each other.

They don't have to use the middleman of

the main session. And then the third

piece is that they can be working at the

same time. It doesn't have to be agent

one hands off to agent two and then

agent two hands off to agent three

because that honestly might not even

call for an agent team. Agent teams work

together in parallel and need to

communicate throughout the whole

process. So what do teammates instantly

know when they wake up because we know

that they don't have any context from

the jump. What they do have is they

inherit the permissions from the main

session. So if you're on bypass

permissions then all of your agents are

going to be on bypass permissions. If

you allow all bash commands then those

same permissions will once again be

inherited by the teammates. But the

other thing to know that's very

important is that any of your files, any

of your MCP servers, any of your skills,

all of the teammates can use and access

those things. We also have a really cool

ability to use something called plan

approval mode. So you guys know how I've

told you always start in plan mode. If

you plan with your main session before

anything actually happens, it's way

better. What we can do is we can have

all of those agent teammates plan first

and they have to basically get their

plan approved by the main agent before

they're actually allowed to go execute.

So, it's really cool. You could also set

it up where you're actually the one who

has to approve every single plan. But, I

think it's probably better to just have

the main session do that. Or maybe even

one of the teammates is just the plan

reviewer and approver. So, I wanted to

talk about some common pitfalls or

mistakes that you might be making and

what the fix could be for that. So, the

first one is if the agents keep asking

permissions and they keep stopping for

that, you can preapprove certain tools.

So, that would be in your project

settings or your local settings. you can

allow certain commands and that way they

won't stop to ask you something every

couple seconds. If the deliverables

aren't coming out feeling holistic,

maybe they're being overwritten. So,

make sure that you assign file owners.

If you spin up an agent team and you

realize that one of the agents isn't

really doing much or is just sitting

around, then maybe you want to

specifically make sure you're assigning

each agent work or some sort of

dependency in your plan in your prompt.

If you're burning through way too many

tokens, just use fewer agents. If it

seems like your agents are losing work,

then tell them to basically store

everything as a temporary file that they

can then call on later. And if you're

getting the wrong approval and it just

seems like it's off, then maybe just try

to have you be the one who approves

things to start until you understand the

flow of how these teams work a little

better. All right, so next I wanted to

talk about when to use agent teams

because like I said earlier, they can be

slow and expensive. So you really just

want to use them when you need something

pretty complex done and you need lots of

different specialized agents. So think

about using them if your specific

process or project has multiple

different areas. And that way you can

have one specialize in each of those. If

you need those things to be done in

parallel, if you need them to be able to

react to each other, assign tasks to

each other, communicate with each other,

and if something needs to be done at a

really high quality, and you want tons

of different steps to make sure, then an

agent team is probably a decent idea.

Now, if you have a process that could be

done sequentially, meaning every time it

basically goes 1 2 3, and those steps

are dependent on each other, then maybe

an agent team isn't the right call.

Maybe that's just sub agents. If you

need everything in one specific

conversation history or one context

window, then don't use teams. If you're

just kind of working on the same files,

don't use teams. And if it's a very

simple task, then agent teams would be

overkill. There might be a lot of times

where you'd be able to use sub agents

instead. Like I said, with sequential or

if you need a very focused result, if

you don't need the agents to

communicate, and if you want to save

some tokens, because once again, if you

have three sessions running, that's

basically going to be three times the

cost. So if you have five, it'll be five

times the cost. Which means I like to

stay around maybe two to five agents

max. You can keep them running parallel.

Otherwise, you can use sub agents and

make sure that you are shutting them

down if you see them early on going off

down the wrong path. Which is another

reason why I think it's helpful to use

the T-Mox version so you can actually

see them in that split pane view. And

when I say shutdown, which is kind of

what we saw earlier, I just mean

basically at the end of every session

saving your work. Because remember right

here how we saw the main session say,

"Hey, this is a shutdown request." The

researcher agent here could have said,

"I'm not done yet. Let me save stuff.

Don't shut me down yet." So when the

teammates actually confirmed that

they're ready to be shut down, that

means that everything's good. And we can

essentially cleanly save that work. So

everything gets cleaned up and then

we're good to close the session and shut

down that agent team rather than just

force killing it right away where things

might be all out of control and not

cleaned up yet.

So when you give a tool as powerful as

cloud code access to literally control a

browser, if you think about it, you can

actually automate anything, whether

that's stress testing an app,

downloading reports, or even playing a

game like you guys saw in my other

video. So today I walk through three use

cases that you can use when you connect

Playright CLI to cloud code to control

your browser. The first one is having it

actually QA a web app and finding bugs

and then fixing them. The second one is

searching for dentists and finding their

contact information. And then the third

one, a question that everyone's asking

is can browser use actually control

sessions where you need to be logged in.

So I show off what I'm able to do in my

school account. So I don't want to waste

any time. Let's get straight into the

video. All right. So I am in a fresh

cloud code project. As you can see, I'm

in a folder called browser automation

demo, but there's nothing in here just

so you guys can follow along with

exactly what I'm doing. So, the first

thing to do is install Playright CLI so

that we can actually do some browser

automation. So, I'm just going to go

into plan mode and I'm going to say,

hey, cloud code, I want to use Playright

CLI in order to do some browser

automation stuff. Whether that means

testing out web apps or taking

screenshots of things, whatever the

case, I just need you to figure out how

you can install this for me and then go

ahead and build a plan and let's do it.

So, I know I'm telling you guys to use

Playright CLI, but this is literally

what I did when I decided I wanted to

try out some browser automations, except

for I said, "Hey, I need you to research

the different tools and the different

pros and cons and help me figure out

what I should do. I played around with

Chrome DevTools for a little bit, but

now I'm using Playright CLI." And one

reason for that, while we're letting

this load, is that if I do /context in

here, you can see that the Chrome

DevTools MCP takes up so many tokens

because there's so many different tools

and each tool has a description. So,

that's why I was like, hm, maybe I don't

want to use the MCP server. Let me just

go ahead and try this Playright CLI and

it works really well. All right, so the

plan is done. We have an empty project.

We're going to initialize the project,

install Playright, create a demo script,

test things out. I'm going to go ahead

and accept this plan. And now I'll check

in with you guys when that's done. All

right, so you can see that it is done.

It's been installed and then it also

tried it out already. So it ran a script

to open up this page and then screenshot

it. And that got saved right here. So as

you can see, it was able to do that. It

was able to take a screenshot, which

means that everything is working. So now

that we have this initial stuff set up,

I'm just going to go ahead and do a

slashinit to basically just initialize

the environment and give us a claw.mmd

file. All right, so there are tons of

great use cases when it comes to using a

browser automation, whether that is

looking through Amazon or applying to a

ton of positions or, you know,

downloading reports from websites that

don't have an API. And what's awesome

about this is it will build out these

scripts that run the browser automation,

right? And when you pair those custom

scripts with a skill, it gets really

powerful because then that process of

opening up the browser and doing certain

things becomes consistent and

repeatable. But one thing that I think

is really cool about browser automations

is the ability to basically test things

and automate QA. So an example I wanted

to walk through with you guys is I'm

going to use cloud code in here to build

us a quick web app that's going to be

like a multi-page form and I don't want

to test it myself. I want to have it

test it and then it has to find the

bugs, find suggestions, and then fix

itself. So, it's going to be us building

a web app or a form and it's going to be

like completely hands-off. That's the

goal at least. So, let's hop into plan

mode and let's get started. I need you

to build me a form submission website.

Now, I want this to basically be one

page per question. So, as soon as I open

up the page, it should ask me for my

first name and then there should be a

button that prompts me to hit enter.

When I hit enter, I go to the next page.

And then I have my last name. And then I

have my phone number. And then I have my

business. And I have maybe, let's just

say, eight questions about me and kind

of getting me onboarded into this, you

know, fake business or whatever. I just

want to do this to see and test the

functionality of what you're able to

build me here. Okay. So, that is phase

one. Phase one, we're going to get an

initial version of the website. And then

before I even open it up and test it,

we're going to go into plan mode again

and see if just cloud code with the

browser automation can test it, iterate,

test it, iterate. Okay, here is our

plan. Multi-page onboarding form. The

user wants a polished multi-page

onboarding form. We have the

architecture. There's 12 total

questions, which look good to me. We've

got some files. It's going to make some

implementation details here. And all of

this looks good to me. So, we're going

to go back into the main session and

accept those changes. Okay, so that just

finished up. We have the files have been

created. We've got a server that this is

running on. It's going to be on a local

host. We also have 12 one per page

questions. And what I noticed it doing

is it was taking screenshots and I

didn't even tell it to. So, if I open up

screenshots, you can see we now have

these pictures. So, let me just look at

these. We've got number one, which is

what is your first name? Number two,

last name, best phone number to reach

you at. There's even, if you can see,

there's like one of those scroll bars at

the top where it's like showing, you

know, how many questions in they are.

So, for a oneshot prompt and the fact

that it's already flipping through and

taking screenshots, I'm pretty

impressed. But, we have to see how it's

able to actually test it out. So, now

I'm going to go back into plan mode and

I'm going to say, "Yep, absolutely. Spin

up a server so that you can actually run

this." And then what I want you to do is

use your browser use and test it out. So

fill in the fields, click through, and

if there's any bugs or if there's

anything wrong with the functionality of

the site, make note so that you can go

ahead and fix the actual site itself.

And I also want you to do this in a

headed browser so that I can watch

what's going on. So I'm going to shoot

that off. It's going to make a plan. But

that is one important distinction. By

default, you could say, hey, I always

want you to run playright in a headed

browser. But there is headed or

headless, meaning it could be running

this headless where it wouldn't show us

on screen, but it is still running on

its own tab and clicking through things.

Okay, here is the QA pass. The headed

browser testing, I'm not going to read

this. I think that this is pretty clear

of what we want. I'm going to go ahead

and accept it. So, what happens is for

every kind of like bot that we want to

run, it has to write its own script. So,

I believe that this is this one that

it's writing, which is the test

onboarding.js.

And this is basically what instructs the

bot on what to do. And then when we

wanted to turn this into a skill, which

is basically like QAing our website, we

would say, okay, when you want to QA,

then you run the bot and then you take

the feedback from the bot and then you

make changes and then you run the bot

again. And so that's how we can turn

kind of like all of these different

pieces into an actual process. Okay.

Also, that wasn't even the script. The

script that it's writing for this is QA-

test. So now you see what I mean. Okay.

So the window just popped up. I'm going

to move it into view and we should be

able to watch it fill in. It's did it

did Nathan. Okay, it went backwards. Now

it's on the second one. Nathan Harrison

filling in a phone number. It's

continuing to click through. Harrison

Tech. We've got a email. We've got

founder and CEO. It shows a company

size. Look from a drop down. Okay.

Technology referral. Primary goal.

Website. Continue. And anything else?

Okay. It looks like it's having a little

bit of trouble here now. It keeps kind

of glitching out. But once again, I'm

not going to stop it. I'm going to let

it figure out what it needs to do. Okay.

So it just shut down and now it said

okay found some issues. Let me review

the screenshots to understand what

happened. So what you guys didn't notice

is that in there it took more

screenshots. So we can see now we have

QA and we have all of these screenshots

that it took during that test. So it

says okay the UI looks polished. That's

great. It did look really good. But the

first bug is that enter on text area

didn't advance to review. It stayed on

the notes page. The second bug is that

the review page never loaded. The test

found zero review items and the edit

button was intercepted by a stale page

overlay. And now it was able to use that

feedback to fix the actual bugs in the

site itself. And this is just really

cool because if you've ever built

software or websites or apps or

whatever, there are so many bugs and you

don't always find them until it's maybe

too late or maybe a customer found it.

So, the fact that you can automate QA by

having multiple different headed

browsers or even headless browsers spin

up and you can say, "Hey, you test for

X, you test for Y, you test for Z," and

just have them running and fixing and

running and fixing is a complete game

changer. And now, without me even

asking, it says, "Okay, I'm going to

start the server and I'm going to rerun

the test." So, we're basically getting

it stuck in this loop of testing,

validating, testing, validating, and you

know, it's really, really cool. So, I

think it's doing another quick test just

to see um if it truly is good. But,

okay, nice. So, second test went all the

way through and now it should be

shutting down and telling us what it

learned. As you can see, it just shut

down. So, now you can see it has finally

passed the tests and it goes ahead and

ends the process because now the server

is good. So, like I said, the next step

from there would be to turn that into a

skill. But what else can we do with

browser automations? Because they're

definitely not perfect, right? So, let's

say we wanted to do something on the

web. Let's say we wanted it to just be

able to go to Google, search for, I

don't know, let's just say dentists, and

maybe capture like some phone numbers.

All right, here is our plan. Build a

Playright script that automates Google

search to find dentist offices in

California. We will basically launch the

browser, do the Google search, collect

the links, visit each site, and print a

summary. So, that looks good to me.

We're going to go ahead and shoot this

off and hopefully it's going to be

decent on the first try. I'm going to

tell you guys right now it's probably

not. But what's going to happen is we're

going to have it learn. So, it's going

to open up the browser. It's going to

fail and we're going to say, "Okay, keep

learning. Keep updating the script and

don't stop until you're done." I

literally stepped away to go get water.

And it actually I came back and I saw a

browser open with some dentist offices

up. Wow. So, it visited all five sites

and it was able to find some phone

numbers. Now, that's really cool because

it actually learned while it was going

and it said that Google blocked the

automation. So, it switched to duck.go.

So, I told it this time, don't stop

until it actually finds five phone

numbers. So, it's going to be a little

bit more aggressive. And this time, I'm

actually here to watch it.

Okay, so here we are. It just searched

for dentist office LA. You can see

there's a phone number. I just saw one

on screen, so it probably grabbed that

screenshot. I see another one on this

page. So, it's getting pretty lucky

here. It's finding the phone numbers

pretty quick. But what I just noticed is

it's still going to the site and it's

still clicking on the contact button.

Even though the phone number was up in

the top right visible, it still clicked

on the contact button, which I thought

is pretty cool. So, this time it got all

these phone numbers for these dental

offices. So, naturally, the next

question that I'm sure you guys have is

how could it work on, you know, things

that I'm already logged into? So, let's

just find out. So, I'm going to go to

plan mode and just ask it what would

happen. So, there are a couple of

approaches. We could do persistent

browser profile, meaning it can launch a

browser using my existing Chrome user

data, which already has me logged into

school. We could do manual login and

handoff in headed mode, or we could

connect to a running browser. Okay, so

that's pretty cool. It could open up the

browser. I could sign in and then I

could just basically keep that signed in

and have it do whatever it needs to do.

But I do want to try option one, which

it recommended in the first place. Okay,

so we have the plan which is going to go

into my school community. It's going to

go to the win channel and it's going to

like those posts. So we've got the

context, the approach. Obviously you

guys know what these plans look like.

Let's just see what it did on this first

try and I'm going to go ahead and

accept. Okay, so apparently when it runs

this, I'm going to have to log in

manually the first time, but then in the

future it will basically save that

session. So let's see how that works.

All right, it opened up school.com.

Okay, it opened up school.com.

Okay, so what just happened is it opened

it up and then it closed it and then it

opened it up and it went to my community

and closed it and now I think it's

actually going to let me log in. So let

me try that real quick. Okay, so I

logged in and then the browser shut

down. So now I said, "Okay, cool. I

logged in." Hopefully now when it

launches up this browser, it already has

me logged in. Okay, so there it is.

Nice. You can see that I am already

logged in, which is great. Okay, so it's

trying to find the wins channel. It

looks like it found it. All of these

look like they are wins. Now let's see

what it's able to do here. If it's Oh, I

just saw it try to like the post. Okay,

it just liked that one.

Interesting. So, it's like liking them

and unliking them. So, that's one thing

we're going to have to fix. But, it is

scrolling down. It got to the wins

channel and it is now trying to like

post, but as you guys can see, it's not

perfect. So, I hope that it's able to

realize that it's not really liking

them. Yeah, it's basically going like,

unlike like unlike, and it also just

said liking too fast. So, let's see if

it's able to learn. Okay, there we go.

All right. All right. So, what I'm going

to do at this point is, you know, I've

seen enough. I'm going to shut this

down. And hopefully, it's able to use

that feedback to get better. So, the

login persisted. It found the wins

channel. It even found the heart-shaped

SVG buttons, but it crashed during the

page evaluate for liking. So, it's seen

all that and now it's going to make the

script even better. So, I will say with

browser automations, I think that this

is completely normal, which is why I had

a little bit of doubt earlier in the

dentist example, but literally every

time that you use the script, it's going

to get better. So, it's about to run it

again. Let's see how it does. This time,

it was able to just find the wins

channel. Now, one thing I might want to

tell it is I might want to sort it from

newest posts rather than just going

straight to the winds channel. And it

went ahead and shut down again. So, it's

continuously trying to learn and get

better at this script. I'm actually

going to stop this and I'm going to try

to course correct it a little bit. So,

I'm going to go into plan mode. I'm

going to say,

so a couple issues from the first couple

runs. The first thing is that it was

hitting the like button like four times.

So, it ended up not even liking the

post. The second thing is once you

switch to the wins channel, try to

filter the posts by newest. So, there's

a little kind of sandwich bar menu

option near the channel filter. And that

will allow you to change the view to

newest. And then you can go through and

make sure that all of the posts are

liked. You can tell that they are liked

because the thumbs up icon on the post

will be yellow rather than gray.

All right. So, we got the browser open.

Nice. It was just able to switch to

newest.

And now it's going through and liking.

It skipped over that one because it

already liked it.

Yeah, this is awesome. This seems to be

doing the trick.

It's liking my own posts, which is a

little bit eh, but besides that, it's

actually working. And it's skipping over

the ones that are already yellow, which

is great. It even just went to the next

page, and it's still liking. So, this

would go through and like every single

post in the wins channel. So, I'm going

to shut that down now just because I

don't want it to go ahead and do all

that right now. But, that worked and it

took what, maybe four or five

iterations. And now what I would do is I

would build a skill out of that. So, I

could just say, "Hey, run the school

like skill." So anyways, I know that

that was kind of a simple use case, but

the point I was trying to prove is that

yes, you can automate stuff in areas

where you need to be logged in. And also

like school is one of the least

automation friendly platforms ever. So

there's so much stuff that I do in there

that's very repetitive. And now I could

build out different bots and different

scripts and skills in order to help me

manage some of that, you know,

repetitive stuff. Creating pages,

switching up links, reorganizing the

community, stuff like that.

All right, so we're really flying

through this course. Unfortunately, now

we have to talk about some stuff that

might not seem as fun. So, we're about

to hop into some things that are a

little bit more complex. Like I said,

kind of boring, but really important to

understand. So, we're going to get into

some stuff with permissions, context

management, GitHub, and work trees.

Okay, welcome back to the fun stuff, the

slides. You guys can obviously tell I

enjoy the slides because I'm sitting

down and normally I am standing up. So,

let's get into it. So, we're going to

talk about context management a little

bit and then some GitHub stuff and some

Git work trees stuff. So, we've talked

about context management a lot. We've

talked about cloudmd files a lot, but we

haven't really spent a lot of time on

like strategies to basically make sure

that the window doesn't fill up super

quick and that we keep the quality of

our executive assistant high or the

quality of our project high. So, let's

get on into this one. The first tip, of

course, is cloudmd. keep it lean and

focused because it is injected at the

beginning of every conversation. This is

really really really important like

this. Cutting down your clawb file from

a couple hundred lines, you know, 5 6

700 to 100 will make a huge difference

right off the bat. So what you do is you

treat this as the never forget rules.

You treat this as the source of truth

that Claude Code needs to know every

single time before it messages you

because there's a lot of things that it

it's nice to have but you don't need to

have. So all of your detailed reference

docs that are usually the nice to haves,

put those somewhere else. As long as

Claude Code knows where to find them,

you're set. So

this was the example of my executive

assistant, right? You are Nate's

executive assistant. here are full

details about me or my work or my team

or my current priorities. That's one

example. You could also do things like

this. So, you have the Google Workspace

CLI. You're authenticated as Nate. Um,

now if you need actual information about

how to use this, then just look up this

doc. So, if you can't do it on your own

and you're running into issues, then you

know, you can go right here in the

references folder to a markdown file

called GWS CLI reference and you can

find all the other operations that you

need. So super simple. You do the same

thing with your skills. You do the same

thing with other rules, stuff like that.

The next one is to use slashclear and

slash compact strategically. So we've

talked about this before, right? So use

slashclear to wipe history after big

tasks or if you're completely switching

topics, but before you clear, what you

can do is you can make handoff docs. So

you can literally have it, this is

essentially compacting, create a doc

about what you were working on, whether

that's going to be just for the short

term, a temporary file or if it's going

to be a long-term memory file and then

when you move over to a new session,

it's almost like you didn't even really

move to a new session because all the

information is right there, which is

basically what compacting is, right? It

summarizes and retains the essential

information midsession so that you can

keep certain items and you can keep

certain conversation history.

The other thing is to visualize your

context a lot. So slashcontext really

powerful tool. I've showed that a few

times and you can see what's eating up

tokens. And one thing that I realized

when I was doing this is that MCP

servers take up so many tokens and

sometimes it's just not worth it. So I

think that's another tip that I have on

this slide, next slide. So I won't dive

into that too much, but this allows you

to identify waste and delete things that

you're not using. If you got something

in your context of that project that's

taking up, I don't know, let's just say

a percent or two of context every every

time, get rid of it. if unless you're

using it, right? Like it's the same

thing of looking at your budget, like

what's coming out of your account every

month. What subscriptions? If you're not

using the subscription, don't keep

paying for it. Get rid of it. So, this

is what it would look like, right? You

do slashcontext. You can see everything

takes up tokens. You can see in this

project when I have a brand new session,

I'm already at 24,000 tokens. So, that's

over a tenth. I have system prompt,

system tools, MCP tools, uh, custom

agents, memory files, skills, all this

stuff. Here's an example of just Chrome

dev tools. Every single tool takes up

tokens because every tool has a

description of what it does so that

Cloud Code could see that description

and grab it. And that's where these

tokens come from. We also have custom

agents. Same thing. We have memory

files. We have skills. They all have

tokens that they take up natively. So

this is how you can eliminate that

waste.

Next we have plan upfront and work in

phases. So create a dedicated plan saved

to a file and then work off that plan.

Now let's say we have a we have a plan

for a app and the app has five stages.

Let me work with cloud code. Let's get

us that plan doc. Okay cool. Save the

plan doc. Now I can I can clear I can

open up a new session and say hey look

at this plan doc this is what we're

doing you're on phase one help me do

this like you know what you know what I

mean you have that context now without

having to stay in the same session. So

that's one tip to do something like

that.

Limit your open sessions. So it's really

cool that you can do you know like 10 to

15 sessions at once. I tend to not do

that anymore. I I used to for a while

because I thought it was so cool because

what happens is you can't juggle and

understand how much context is going on

in that many sessions. Like you could,

but it's harder to

be aware of how much context you've

used. And the the issue there is that if

you're not aware, you might run into

context rot, right? And if you run into

context rot, that means that your

outputs are probably worse or they have

to be double checked by a human more

likely. And if you're running that many

sessions, it's easier to lose track and

it's easier to just think, "Oh, it's

good. AI did it. We're good." So that's

why I would not recommend doing any more

than three to four parallel sessions,

keeping actual tabs on what's going on.

Sub agents for isolated tasks. So

delegating fileheavy investigations to

sub agents. These sub agents run in

separate context. And there's, you know,

a full video in this course about sub

agents, but basically the idea of if you

have tons and tons of data, so like

let's say you're working in a main

session and you have a full YouTube

transcript, a 15-minute YouTube video

transcript that you want to read in the

session, don't have your main session do

it. Say, "Hey, sub agent, read this.

Give me the key highlights." And that

way, the main sessions context doesn't

get polluted with all of that non

nonsense that it doesn't need.

shared memory files for multi- aents.

So, this is really cool because you can

have multiple agents working across the

same plan doc or task list. Now, we do

have agent teams, which once again, this

course has a video about, but if you

want to basically Frankenstein your own

way and have more control, you can have

multiple agents look at and work off of

the same file. The thing you have to be

careful of though is if they're working

in parallel, you run the risk of having

them overwrite each other. So as long as

you can manage that and have that sort

of like persistent memory across

different agents without them

overwriting, then it is a very powerful

technique to potentially save yourself a

lot of tokens.

We also have local semantic search over

GP. So if you have large large code

bases or projects, GP, which is one of

the the tools we learned about, is going

to search through things in a much less

efficient way than using like actual

semantic search because that's kind of

more of like the, you know, the meaning

search rather than just like keyword

matching. So benchmarks have actually

shown that you can get a 97% reduction

in tokens when you're doing local

semantic searches like that. So that's

just something to keep in mind. I have

not yet truthfully gotten to the point

where I need to do this, but it is

something to keep in mind.

Okay, now let's move on a little bit to

GitHub and work chase. So this is really

important, right? Because you need to

understand where things live, how you

track version control, how you can

collaborate, how you can move local code

bases between devices and then work

trees. So basically making sure that

you're not breaking anything. So these

are two really important concepts to

understand. And before we get into all

this technical stuff that might seem

overwhelming, just know this.

AI knows GitHub and Work Trees so well.

They know GitHub and Work Trees so much

better than you ever will. Unless you're

maybe from a developer background, they

certainly know GitHub and Work Tries

better than I ever will. So, all you

have to do is be very strategic and

smart about what you want and what you

don't want. Meaning, if you want to save

your work, if you want to roll back to a

different version, if you want to share

this with someone else, just use your

natural language and cloud code will

help you do that with GitHub or with

work trees. It's super super simple. It

just kind of goes back to what I talked

about at the very very beginning of this

course where I was like be genuinely

curious. That's like the number one

mindset shift. Okay. So there is a

difference though between Git and

GitHub.

Git is a version control system. It is a

tool that tracks every change that you

make to your projects and this can be

locally. Think of it like a time machine

for your project. So every time you save

a meaningful change, which is something

that they call a commit, Git takes a

snapshot of your entire project at that

moment. So later if something breaks you

can effectively rewind. So it's like

you're getting a checkpoint, right?

So a few concepts, a repo or a

repository that's basically a folder

that git is watching. It contains all

the files plus the full history of every

change ever made and it's like you know

a bank account for your code. It has

everything, all the transactions,

everything. Now what is a commit? This

is a snapshot of your project at a

specific point in time. So each commit

includes what you're describing or sorry

it includes what you've changed and

describes why and basically like hitting

save on a word doc or a video game or a

video file

branch. This is a separate copy of your

project where you can make changes

without affecting the main version. So

almost like you clone it, you change

things and then if you like it, you can

merge it back in. The default branch is

usually called main. And when you create

a new branch like feature login, you're

essentially saying, "Let me try

something without risking the stable

version." So it's almost like the way

that you have, you know,

workflows that are published and

workflows that are in draft mode or

inactive. And you would never want to

make live changes to the published

version. You would change things in the

test environment. You would change

things as a draft. And then once you

like it, you push that to prod or you

push that to main or whatever different

terminology you have. It's that same

concept, right?

Um, and that's where push comes in,

right? Uploading your local commits to

the online version of your repo. So,

syncing to cloud. A pull is downloading

the latest changes from the online repo

to your local machine. So, you're

pulling it in. And then a merge is

combining the changes from one branch

into another. Once your feature is done

and tested, you can merge it back into

the main. So, that's how we do

everything here very, very safely.

GitHub. So, GitHub is basically the

cloud service built on top of git. So

while Git runs on our local computer and

tracks our files, GitHub hosts them

online so that you can access them from

anywhere. You can back them up, you can

collaborate with others, do whatever you

need. And that's how you can maybe take

your executive assistant that's right

now locally, push to GitHub, and then if

you have a laptop and you want to go on

a vacation, you can bring your laptop

with you and pull in the repo. So you

still have your executive assistant

there. So think of it like this. Git is

the engine that tracks your changes.

GitHub is the parking garage in the

cloud where your project lives so that

it's safe and accessible.

What does GitHub what does GitHub

actually give you? Well, cloud backup,

collaboration, pull requests, and

version history. So, cloud backup is

pretty self-explanatory. Um,

collaboration means that multiple people

can work on the same project without

overwriting each other's work.

Pull requests means that you can propose

changes and have them reviewed before

you merge them into the main project.

And so that's how you can have multiple

engineers working on the same GitHub

repo, all pushing different feature

requests and, you know, working on their

own things and merging it all back into

the main environment safely. And then

you can also see version history, which

would basically just mean, let's say you

have a project, you push 10 different

commits. You can see each commit. And if

you needed to roll back to a certain

commit, you could. You could see who

made the commit. You could see what was

the purpose of that commit. You can just

see everything, right?

Okay. So the basic workflow would be

create a GitHub repository for your

project. clone a copy of it to your

local computer. Create a branch for your

new feature or fix. Make changes and

then commit. Push the branch to GitHub.

Open a pull request to propose merging

your changes into the main and then you

review, approve, and merge. That's

typically the way that it works when you

have a team working on a project. So,

this is exactly how professional

developers and teams work and it's the

same workflow cloud code uses behind the

scenes when managing the project. Once

again, cloud code understands these best

practices and when you need to save

things or roll back, it will help you do

that.

So now that you understand all that

stuff, work trees should probably click

a little bit better. So a work tree lets

you check out multiple branches from the

same repo at the same time, each on its

own folder on your computer.

So the problem is that normally in git,

you can only work on one branch at a

time within that folder. So if you're

building out a new feature and suddenly

you need to go to a different branch,

you would have to either stop what

you're doing and save it or you would

have to just like commit it and it might

not be finished yet. So it's risky. So

this problem is solved with work trees

because you can basically just create a

second working directory just to work on

that branch or just to work on your own

fix. So your original work basically

just stays there and you just open up a

separate one and they they're isolated.

They don't touch each other, right?

So, Cloud Code has built-in native

support for git work using a command.

The good news is you don't ever have to

really run this if you don't want. Cloud

code can do it, but you could also, if

you want full control, you could start

up your own work tree. This means you

can run multiple cloud code sessions at

the same time, each working on a

completely different task without any of

them interfering with each other. So, it

is very, very safe. Okay, great job

getting through the stuff that I thought

was the most boring about learning cloud

code. And now let's just kind of get

back into some more fun stuff. So I'm

going to go over some hacks with you

guys and then just show you some cool

things that you can do with Cloud Code.

And I think it's pretty fun. So let's

get into it.

These are the Cloud Code hacks that took

me from a complete beginner to

mass-producing workflows and building

websites, apps, and AI agents in real

time. So today we're going to be going

from beginner hacks all the way to

advanced power user stuff. And the best

ones are saved at the end. All right, so

starting off with our beginner hacks.

Number one is to run /init on every

project. So if you already got an

existing project with files already in

there, the first thing you should do is

open it up and type /init. Cloud code

will then scan your entire codebase,

your folders, your files, and it will

generate a cloud. MD file, which is

basically like a cheat sheet for that

project. It'll map out your

architecture, your conventions, and any

key files that you have in there. So

instead of having to reexplain your

project every session, Cloud will

basically just contextualize everything

and initialize everything and know what

you're working with. And if you're

starting a new project from scratch,

then you can have cloud code help you

create that cloudmd file yourself just

by explaining what's the goal of this

project, what text stack you want to

use, or any rules or key folders and

files. All right, number two is to set

up a status line. So if you're working

in the terminal, you can type / status

line and tell cloud code what you want

to see, your model, your context

percentage, cost, whatever. It basically

generates a little script that sits at

the bottom of the terminal. So as you're

talking every single time, you can just

see that status line. It's just kind of

like a mini dashboard for your session.

So, it's really helpful to always be

able to see how much context you have

left so you can avoid context rot. Hack

number three is using voice input. So,

cloud code just shipped a native/v voice

command, which means you can literally

just talk to your terminal and have it

code for you now. So, it's still rolling

out. It will be out for everyone soon,

but another good hack would just be to

use an app to actually be able to voice

dictate anywhere. So, if you want to see

the tool that I use, you can check out

the description. Now, I can just talk

and words will appear anywhere. Hack

number four is to keep your context

small. So don't dump your entire

codebase into a conversation. Only give

Claude what it needs for the current

task. So try to break big problems into

small focused steps. The less noise in

the context window, the better Claude

performs. It's simple, but a lot of

people ignore this. Hack number five is

to use /context to find your token

bloat. So if you do /context, you'll see

exactly what's eating your tokens.

Whether that's system prompts or file

contents, MCP servers, whatever it is,

all of that gets broken down into

percentages. So if your session feels a

little bloated, you can actually

investigate it, diagnose where the

problem is, and then restructure. Hack

number six is to compact at 60%. And

also clear between tasks. So when your

context hits around 60%, then type

/compact and cloud code will compress

your conversation history so you can

keep going without losing important

stuff. And something interesting is that

you can actually do a /compact, but you

can tell it to keep certain things like,

hey, / compact, but keep all of the API

integration decisions and database

schema. So Cloud will automatically

shrink everything down and preserve the

stuff that you need to keep in there.

And if you're actually going to switch

to a completely different task and you

don't need that conversation history,

then use slashclear to just wipe the

slate clean and you're starting from a

new conversation. But luckily, you still

have your cloud. Mmd, you still have all

the other files. So it's not like you're

actually starting from scratch. So hack

number seven is to always start in plan

mode. So that means you can hit shift

tab to cycle between modes or just

choose it manually. And once Claude's in

plan mode, it can still read, it can

still research, but it won't actually

change anything. So Claude will outline

the steps. It will ask clarifying

questions and it will map out the

approach before writing a single line of

code which has been shown to improve the

quality. Now once you like the plan you

switch out of plan mode. Tell it to

execute and this alone will dramatically

reduce how many times that you have to

go back and correct Claude. Hack number

eight we have to treat Claude like a

junior developer which means don't

always give it direct commands like

write me a function that does X but try

to understand how you can give it

problems. So saying, "How should we

handle growth tracking?" And let it

think through the approach because when

it makes its own assumptions and it

thinks through decisions, you can ask it

to explain those. And this has also been

shown to get better outputs when Claude

reasons through the problem first. So

it's like plan mode, but now you're

having it think a little bit deeper.

Okay. Hack number nine is to make Claude

ask questions. So a lot of times in plan

mode, it will do this natively, but you

can actually tell it to invoke its ask

user question tool. You can tell it

continuously ask me questions until

you're 95% confident that you understand

exactly what I need and exactly what you

need to do. And once again, this

alignment helps you from having to go

back and forth with, you know, three or

four rounds of revisions. All right,

hack number 10 is build self-checking

into the to-do lists. So, you know how

Cloud makes a to-do list when it starts

building? Well, you can actually build

verification steps right into that list.

So, let's say one to-do is to build the

website. The very next to-do could be

take a screenshot of the website and

check that everything looks right. And

then maybe the next step is to open

Chrome DevTools to use the browser and

make sure that there are no actual

errors in functionality. So you're now

baking quality checks directly into the

execution plan. So Claude isn't just

building stuff and handing it to you for

feedback, but now it's building

something, checking it, making sure

everything's good, and then getting your

feedback. And another cool thing that I

like to do here is say, don't move on to

your next to-do until you're 95%

confident that that to-do is good.

Because it's AI, it's really hard to

oneshot what you're looking for, but

you'd rather have it one shot 90% of the

way there rather than one shot 60 or

65%. Okay, so those were our beginner

hacks. Now, let's step it up a little

bit. These next ones are for the people

who are already kind of using Cloud Code

a little bit and want to move faster.

All right, so hack number 11 is to

deploy sub agents for parallel work. Try

telling the main session to use sub

aents in your prompt when you're working

on complex problems. Cloud will spin up

isolated sub aents that each have their

own context window. They can each be

using their own model and each agent

works in parallel which means the main

thread stays clean while the sub aents

go do research, write tests or explore

different approaches. When they're done,

they all report back to that main agent

with their findings. So it's like having

a team of developers instead of just

having one. And you can even pair this

with the model hack for cheaper tokens,

which means you can have all the sub

aents running on Haiku for simpler stuff

and your main thread can stay on Opus.

All right, hack number 12 is to build

custom skills. This means you can create

reusable prompt files in your

do.cloud/skills directory. So for

example, you can have one skill called

techdebt.md which tells claude exactly

how to scan for technical debt. Or you

can have one called code review.mmd

which knows exactly how to review your

codebase and then all you have to do is

invoke that skill in natural language or

just use the slash command directly and

it will run that entire workflow

consistently every single time. You can

even commit them to GitHub and your

whole team can instantly use them as

well. So you can automate your actual

SOPs. All right, so hack number 13 is

something that I alluded to a little bit

earlier, but that's basically just using

Haiku for sub aents because you can set

the model for the sub aents that you

spin up. When you have simple tasks or

processing a large amount of data, then

use Haiku. It's way cheaper and it still

gets the job done. Specifically, if you

need a sub agent to go scrape a ton of

different articles, read hundreds of

thousands of tokens, and then just give

Opus, give your main agent just a small

summary or the key highlights. It just

doesn't really make sense to have such a

heavy and expensive model reading

hundreds of thousands of tokens if it

just needs a few bits of information.

And if you do this right, it can really

keep your cost down without sacrificing

quality where it matters. All right,

hack number 14 is to constantly be

refreshing your claw.md file. Once

there's a new discovery about your

project, update the claw.md. Once you've

made some new skills, update the

cloud.mmd. You want Claude to be logging

new patterns, new gotchas, and any new

conventions that it discovered during

your session. So next time that you

start it up, it already knows all of

this. This will help prevent repeat

mistakes, and it will make Claude

smarter about you, your business, your

project, all that kind of stuff over

time. But here's the catch. You don't

want to let it bloat because the claw.md

file is basically the system prompt and

it gets loaded into every single

conversation and everything in there is

going to eat up at your context window.

So I try to keep mine simple and only

put the most important information in

there. I like to keep it between 150 and

200 lines max. If it starts getting

longer than that, then it's time to trim

down some things. Which leads perfectly

into the next hack, number 15, which is

to have claw.md route to other files.

Because it potentially eats so many

tokens, you want to keep it lean, but

you do have a lot of information in

there. But what's cool is you can route

it to different places. So you can have

it link out to separate files for stuff

like style guides or business context or

reference docs. Just point to those

files in the cloudmd so claude knows

exactly where to look and then you're

also not wasting tokens on information

that it doesn't always need because in

its system prompt it doesn't need to

know the exact status of a certain

project but it does need to know exactly

where to go look to find that

information. Hack number 16 is to exit

early and reask. So if you notice that

cloud starts going down the wrong path

don't just wait for it to finish. hit

escape, correct course, and then

reprompt. Every token that it spends

going the wrong direction is just wasted

context. So steer tight and steer early.

At the end of the day, it is AI. Hack

number 17 is to challenge outputs

aggressively. So if Claude gives you

something that's just okay, push back.

Say scrap that, do a more elegant

version or this isn't good enough, try

again with a completely different

approach. Claude will often give you a

dramatically better output on the second

try when you set a higher bar and now it

knows what to not do. The key is once it

comes back with something better, tell

it to update itself. whether that be the

skill or the claw.md so it doesn't make

that sort of mistake again. Hack number

18 is to use slashre for quick undos. So

if you make a wrong turn just try using

slre and claude will roll back to a

previous point in the conversation

without you having to start over. So

it's super quick, super clean. Hack

number 19 is using hooks for

notifications. So if you type hooks, you

can set up a notification hook or you

can just have Claude code do this for

you in completely natural language. So,

for example, what I like to do is when I

have Claude finish up a session or

finish a chat, it sends me an actual

noise notification because now I can

work on something else on my computer or

I can literally have 15 different

sessions of Claude code running and if I

hear that noise, I know that one of them

is done and needs some more input from

me. Hack number 20 is using screenshots.

Just remember that Claude can actually

see and this is a huge unlock which

means you can feed it error messages

which means you can feed it, you know,

inspiration websites. You can also do a

really cool selfch check loop where you

can say things like take a screenshot of

the website and tell me if the layout

looks right. And it will literally

screenshot it, analyze it visually, and

tell you what's off. So, if you remember

one of the hacks from earlier where I

said to have it check itself, when I'm

building websites, I basically have it

design the website, screenshot, and then

implement new changes, and then do that

again. And so, it does like three passes

of building and screenshots before it

even gives me V1. And in that flow, the

V1 that it gives me is so much better

than a V1 that it used to give me. Hack

number 21 is to use Chrome Dev Tools. So

Claude can open a browser, it can

interact with an app, it can check the

functionality of things. And so it's

kind of like the screenshot loop, but

instead of for like websites and design,

it's for actual functionality of like

apps and buttons. This is huge for

front-end work. So definitely give it a

try. But this also means that it can do

things like filling out forms and

potentially like recaps and stuff. But

this is also huge because if there's not

an explicit API somewhere, it can go in

and manually do things. I think that it

could also solve captas, but it's

probably better if you're already signed

in somewhere and all it has to do is

navigate, click buttons, fill out

things. Hack number 22 is to clone

inspiration sites. So, you can take

screenshots of sites that you really

like and feed it to Claude and say,

"Make it look like this." Claude will

recreate the design patterns without

making it look like generic AI slot. And

this is huge for front-end quality

because you could also use the site as

inspiration by taking some of the actual

like HTML styling and feed that into

Claude, too. So yes, Claude could

essentially clone a website, but what

you want to do is take that as kind of a

template and give it your own touch.

Okay, so now we're going to move on to

some more advanced stuff. These hacks

are for people who really want to push

cloud code to its limits. So let's go.

All right, hack number 23 is to run

parallel sessions with git work trees.

Normally when you're working on a

project, you've got it in one folder

with all your files in it. So if you

want to run two different sessions in

the same folder at the same time, they

might overwrite each other's work, and

that's where work trees come in. So

think of workree like basically making a

parallel copy of your project except

it's way more efficient than actually

copying the folder. You just type in

claude-workree

and then that feature name. So claude

will then create an isolated workspace

on its own branch. You could then open

up another terminal and type in the same

thing with a different feature name and

it will open up a different branch. So

now you can be working on the same

project at the same time without having

those coding agents step on each other.

You could have three, four or five of

these things going at once. And when

you're done, you can have them just

merge the branches back together just

like you would with any other git

branch. So all the work can save back to

the main project once again without

overwriting each other's files. All

right, hack number 24 is to use API

endpoints instead of MCP servers

depending on the situation. But here's

what I mean by that. MCP servers are

great because you can look at all the

different tools and execute any of them,

but they load their entire tool

definitions into the context window. So

if you're tight on tokens, sometimes

it's better to just use direct API

endpoints instead. So, for example,

let's say you're using Notion and you

only actually need to be able to read

one database. It makes no sense to show

Claude how to do all of the other

functions if for this specific project

you only have to read one file. So,

instead just hardcode in that endpoint

and now you're saving tons and tons of

tokens. All right, hack number 25 is to

use /loop for recurring tasks. So, you

can type, hey, every 5 minutes check in

on the deployment. And Cloud will rerun

that prompt in that same session every

single 5 minutes unless you close out of

that session. You can set it to monitor

a PR, check error logs, pull a build,

whatever. It runs in the background and

it only interrupts you when something

actually needs your attention. You can

even set one-time reminders in natural

language, like remind me at 3 p.m. to

check in with the team on X. Now, the

only caveat here is these actual loops

will only last for 3 days. So, if you

need a scheduled automation that's a

little bit longer term, then you're

going to want to use the desktop

scheduled tasks. Although, the only

difference here is every time one of

those tasks spin up, it's in an

individual session, so it doesn't have

that context memory. Number 26 is to

host on a VPS for always on sessions. So

if you want to run cloud code on a

remote server, it'll stay running even

when your laptop is closed, which means

you can SSH in whenever you need to

interact, which means you can talk to it

through Telegram anytime. This is

perfect for longunning tasks where you

don't want to babysit a local terminal.

Hack number 27 is you can use remote

control from your phone. So this is a

pretty new feature, but Cloud Code now

lets you control local sessions from

your phone or any browser. You start a

task at your local desk and then you

walk away and you can keep steering it

from your phone. Your code never

actually leaves your local machine, but

it's just the remote connection is on

your phone. So, you can start something

heavy, go grab a coffee, go on a walk,

and you can keep building from your

pocket. Hack number 28 is there's no SQL

data analytics. So, you can connect CLI

tools like Big Query's BQ tool to cloud

code. And then you can just ask

questions in plain English like, what

were our top 10 revenue sources last

quarter? And cloud will instantly

translate that into the right query, run

it, and then give you that answer. No

SQL required. And this should work for

any CLI based tool. Number 28 is

Ultrathink. When you need clawed code to

really think through a hard problem like

architecture decisions, complex

debugging, big refactors, or maybe it's

just not giving you the right output

after a couple prompts, try using

Ultraink. You literally just type the

word and it will go all colorful. And

this means that it allocates the maximum

thinking budget of around 32,000 tokens

before Claude actually responds. So,

don't always use this for a simple fix,

but absolutely use it if you're making

decisions that might affect the entire

system or like I said, if after the

first couple tries it's not giving you

what you want. Hack 30 is to edit

permissions for safe autonomy. A lot of

people, including myself, have shown on

videos using dangerously skip

permissions to make sure that Claude can

just run without asking for approval on

every single step. And yeah, it's much

faster, but it is called dangerously

skip permissions for a reason. So, the

smarter way to go about it is to go into

your permissions and explicitly allow

the commands that you know are safe and

then explicitly deny anything that's

destructive, like deletes or removes.

And now you can actually get to the

point where you have the same exact

speed and autonomy of dangerously skip

permissions without it being very

dangerous. And anything in the deny list

is going to take priority over anything

in the allow list. Hack number 31 is to

use agent teams. So remember how we

talked about sub agents being able to

run agents in parallel that have fresh

context but can't talk to each other?

Agent teams are like that but all of the

agents can talk to each other. So it

gets really really cool. They share a

task list. They can communicate with

each other and they can even assign each

other work. and you can actually talk to

each of those individual agents instead

of just having to go through the main

one and then the main one would

communicate with sub aents. These are a

little bit more expensive and they do

run longer, but they will give you a

much more cohesive output for a big

project. Hack number 32 is context 7

MCP. This one's a game changer. You can

install the context 7 MCP server and

then whenever you need information on

current documentation just prompted to

use that MCP server. The problem that it

solves is that Claude's training data

has a cut off, which means sometimes it

might suggest functions or APIs that

have been renamed or deprecated or just

don't even exist anymore. So, Context 7

fixes that because it has up to eight

version specific technical documentation

about live code examples from thousands

of popular libraries that you probably

need with a coding assistant like

Nex.js, React, MongoDB, you name it. So,

it's able to pull and read all current

documentation and then inject it into

the conversation before Claude actually

starts writing any code. So, it's

basically one command to install and

from there all of your coding agents are

working with much more up-to-date

information and it's a huge quality

improvement. All right, so I know that

we covered a ton of information in this

video. So, what I did is I threw all of

this into a PDF resource guide so that

you can just come back and reference

them whenever you want. That's available

completely for free inside of my free

school community. The link for that is

down in the description. But that's

going to do it for this one. So, if you

guys enjoyed or you learned something

new, please give it a like. It

definitely helps me out a ton. And as

always, I appreciate you guys making it

to the end of the video. I will see you

all in the next one. Thanks, everyone.

All right. So, here I am in cloud code

in the terminal right over here. What

you'll notice is that this agent is

actually my cloud code agent. So, when I

send off this message where I'm asking

it to spin up two researcher agents, one

to research Google, one to research

OpenAI, and then create a visual

diagram, you'll see that this agent

actually gets that task. And now you can

see that we have three agents actually

running right now in parallel. This

one's researching Google AI strengths

and this one is researching OpenAI

strengths. And this is the main one that

delegated the tasks to those two

researcher agents, which you can also

see on this right hand side. That's

exactly what's being ran right now. And

if I wanted to open up another terminal,

so I add another agent. It plops in

another agent right here in which I can

have a different conversation with. Give

me a quick analysis of my YouTube

comment section from the past couple

videos I've made. So now I shoot that

message off to this AI agent in Cloud

Code, and it's going to pick up the task

and start working on other things. As

you can see now, this one is searching

files and finding out what it needs to

do. And you just heard that little

notification noise, which means that

this spun up a sub aent. And you can see

that it was analyzing comments, but now

it needs approval. So basically, what we

have here is a visual way to see all of

the different terminals and sub aents

that we have working in cloud code. We

get notifications and we get visual

things like this that tell us what

they're doing. So I can see that those

sub aents on this lefth hand side are

disappearing. So, I can hop back over to

that first terminal and I'll be able to

see that this first one is already done.

And now the OpenAI one is still being

worked on, which is this agent right

over here. Okay. I don't know where

she's off to, but you can see now that

both of these agents are done. They're

idle. They're done working. So, in the

first terminal, we can see here's the

visual. It came out clean. We have stuff

about Google's edge, Google's gaps,

OpenAI's edge, OpenAI's gaps. So, here's

that actual visualization that it made.

We have strengths, weaknesses for both

Google and OpenAI. Sometimes AI

generation can be notoriously bad on

text, but this one looks pretty decent.

Only a few errors I can see. And then

coming over to the second terminal, we

can see the comment analysis over the

last two weeks. So we've got some pain

points about cloud API costs, edited

into cloud code, getting first client

with zero social proof. We've got most

requested videos. We've got notable

patterns. And then we have recent video

performance snapshot. But I'm sure you

guys could tell that the point of this

quick demo wasn't to actually show you

the outputs. It was to show you what we

were able to do here and how we could

see these two different terminal agents

spin up sub agents and we could keep

tabs on them visually. So,

unfortunately, I'm going to say goodbye

to these agents so we can get on with

the video and I'm going to kill these

terminal sessions right here so I can

actually explain to you guys how this

works and what I think about it. Okay,

so the way that we are doing this is we

are using Visual Studio Code and that's

where I've been using Claude Code as an

extension. If you've been following my

channel for a while, we're using an

extension in VS Code called Pixel

Agents, which basically turns your AI

coding agents into animated pixel art

characters in a virtual office that you

can fully customize. So, I'll have a

link to this page right here, and I will

have a link to the GitHub repository in

the description, but I'll also show you

guys like exactly how you set this up.

So, before we actually jump into that,

real quick, just wanted to go over like

what are we doing here, and what is

Cloud Code because that's the little

agents that we were actually spinning

up. Well, Cloud Code is an AI in our

terminal. It can write and edit code.

code. It can understand our codebase and

it can run commands on our behalf. And

what's going on when you're using a

coding assistant like cloud code is you

basically are just looking at terminal

or you're looking at what the AI model

is thinking and what it's doing. But

what's actually happening behind the

scenes is files are getting read, plans

are being created, code is being

executed, and tests are being ran. So

there's a lot of stuff going on that we

don't really visually get to see,

especially when we start to spin up tons

of parallel agents and have different

terminals running. So basically what

happens is cloud code is working. It

creates an activity log that already

happened by default and pixel agents

basically just picks up that activity

log and then displays it in some sort of

animation. It's honestly a very similar

flow if you watch the way I set up my

OpenClaw personal assistant and I could

see what he was working on and if he

spun up any sub aents. And like I said,

it's pretty cool to be able to monitor

our different agents at a glance rather

than having to flip through different

terminals, especially because I love to

multitask when I'm using Cloud Code. So,

one monitor I'll be coding with stuff

and the other monitor I'll be working on

other things and I can just kind of

easily glance back and forth. So, if you

want to actually try this out for

yourself, it's super easy. You just have

to go download Visual Studio Code if you

don't have it already. Unfortunately,

right now there's only support for

Windows. So, if you're on a Mac or a

different operating system, I don't

think you can use this yet. This

literally came out like a few days ago.

But anyways, once you are in a fresh

instance of VS Code, this is what it

will look like. And what you'll do is on

this left-hand side, you'll come over to

extensions and you'll literally just

type in pixel agents. And if you type in

pixel agents, you'll be able to see

right here pixel art office where your

cloud code agents come to life. This is

the one that I installed and have just

showed you as a demo. It's fairly new,

but I am going to go over some security

stuff near the end of the video. But you

could read through this to understand

what exactly this does. You basically

have one agent per character. You have

live activity tracking. You can design

the office with the floors, the

furniture, everything like that. You can

see speech bubbles. you get sound

notifications, sub agent visualization,

and there are six different characters

that could spawn. It'll go into some

requirements and it will go into some

things about how to actually use it. But

if you want to test it out, then hop in

here. And here's where unfortunately it

says that it's right now Windows only

testing. And on the road map, you can

see that there's lots of things they

want to add like having cloud code agent

teams because right now it's just like

parallel agents. So anyways, once you

have installed that, what you're going

to do is open up a folder. So, let's

just say you come to the explorer and

you open up a project that you want to

be working in. So, here I just opened up

my Herk 2, which is basically like my

second brain executive assistant type of

deal. It's really weird, but if you want

to get this project to work, your folder

cannot have a space or a period in it.

As you can see down here, this used to

be called Herkpace 2.0 and then it was

Herk 2.0 and now it's HERK-2. So, make

sure you don't have those things in

there if you want the pixel agents to

actually pick up the activity log and

actually reflect what you're doing.

You're welcome. I had to learn that the

hard way. So once you're in here, you're

going to open up the terminal. So if I'm

on Windows, I'm going to do control and

then the little tilda. And this opens up

the terminal. And then here is where you

can see I have a pixel agents tab, which

opens up the little workspace. Now what

I want to do is I want to see half and

half. So I basically grab this and drag

it to the sidebar, which lets me look at

it over here. And then all I have to do

is click on plus agent. And that

basically opens up a cloud code terminal

on the right hand side. And it spawns in

an agent right here. As you can see now,

right now, this agent is idle because

it's not working on anything. So, if I

go ahead and say, "Please spin up a

research agent and just find out what's

going on with small businesses and AI

adoption." And I go ahead and shoot that

off, then this agent should pick up that

task, and it should also spin up a sub

agent. I'm going to add another one that

opens up another terminal, and I can add

more and more agents. So, we can see

that we could watch all five of these

different terminals run at the same

time. And then what you can do in here

is you can go to your layout and you can

change things up. So I could move around

this plant for example. I can move that

right here. I could go to furniture and

I have storage. I have tech. I have

decor. I have all this kind of stuff. I

could literally just put a monitor in

the middle of the kitchen floor if I

wanted to. And I could keep adding more

and more. So it's kind of funny. You can

fully customize the way that this looks

and um the colors of like the floors and

the walls and things like that. Now, the

other setting that you can really play

around with would be opening the

sessions folder to see what's going on,

which opens up like a folder like this

to see activity log and stuff. You can

also go to the debug view to see what

the agents are actually working on. And

you can turn on or off the sound

notifications, which is pretty cool. You

can obviously use something like hooks

to do that either way, but it's nice

that that is now sort of native with

this extension. So, I'm not going to

spend too much time here really. I think

you guys all understand exactly what's

going on. You can see that this agent

just finished up. Great timing. I

thought I should wrap up this video by

actually just talking about like what is

the point of this? Is this just like

useless? So my first point is about

entertainment. I think that there is

value to having this as just like kind

of something that's fun. And the reason

I say that is kind of twofold. The first

one is I a lot of times like I said

earlier have two monitors up and I'll

have cloud code going over here and I'll

be working on other things here. And it

is kind of nice to be able to look over

and just see like how many agents are up

or you know do I need to load them up

more tasks. But the other piece of it is

I think that it's visual and that might

lure some people in who aren't super

technical or who are intimidated by

looking at a terminal. I think it's very

similar to how nitn started to blow up

is because they visually had some good

elements that people felt like they

could actually understand just by

looking at and that kind of leads into

my second point which is about that is

exactly what AI coding is lacking is

visual elements because kind of like I

said earlier what we're looking at is a

terminal or you know basically a chat

window when in n or something like that

you're seeing visual workflows you're

seeing the process of the data and

you're seeing things be built or you

know changed now obviously pixel agents

isn't that it's not a representation of

what's they're actually doing. It's just

like showing you how many are working.

But I definitely think it's a step in

the right direction cuz I think

ultimately where I'd love to go is to a

place where claude code builds me, you

know, workflows and automations and it's

showing me it building them in an NAD

style interface where I can see the flow

and then we can talk about multi- aent

monitoring. There's a lot that can go on

with different agents whether you run

them in parallel and different terminals

or you've got sub agents or you've got

agent teams. And it was kind of cool in

here that you know each of these people

are their own terminal. And so if I see

four of this girl, I know that that is

one main and then four sub agents.

Whereas all of these are just different

agents running in terminals because they

are different things. Parallel agents,

you know, four different terminal

agents. Sub agents are a parent

delegating tasks to different sub aents.

Those sub aents can use different models

and they have, you know, their own

independent context. And then you have

agent teams which pixel agent doesn't

yet actually show but agent teams work

together a little bit better. They don't

share context necessarily but they share

a task list. They can talk to each other

and they understand when the other

person is done or the other agent is

done. And even Boris the genius who is

kind of like behind claude code said

that he's using you know five agents in

his terminal at all times and then maybe

another 10 on the web or something like

that. So he's always working with tons

of different agents. So, I am really

interested to see what Cloud Code does

around sort of like more native

visualization. So, real quick, let's hit

on the security of this plugin because

you should really only be installing

extensions that are verified or that you

know are safe. So, before I installed

it, I just looked into it a little bit.

The publisher is named Pablo Deuca. He

is a verified publisher on the VS Code

marketplace. I looked into his

background and he is a real person. He

is a co-founder of a company and he has

a GitHub repo with 1300 stars and over

100 forks. So I think that that means

that he's got a little bit of

credibility to him. He didn't make some

sort of fake profile to put something up

there to steal your data. So we looked

at some key things like outbound network

calls, data xfiltration, shell command

injection, suspicious dependencies,

credentials, secret handling, file

system access, and remote script

loading. And we didn't see anything. So

it doesn't look like it sends data

anywhere. It doesn't collect anything.

It doesn't run any commands and

everything is staying on your machine.

So that is why I felt confident to

actually install this and test it out.

So, I just wanted to share my experience

from a security perspective. So,

overall, the way I feel about this is

that Pixel Agent just tells me that an

agent or agents are working. What I

actually want to know is what they're

building, what decisions they're making,

and whether it's about to do something

that I'd agree with or disagree with.

That's the real product that I think we

need when it comes to visualization.

Because us as humans, we're moving into

this world where we really just have to

be really good managers and keep our

agents and our sub agents on the right

path. And the best way to do that is be

able to just see all the time what's

going on. Stop things before they go

wrong and proactively keep giving them

more work so that they're never just

sitting there idle. But anyways, that is

going to do it for today. If you guys

want to dive deeper into all this kind

of stuff and nerd out, then definitely

check out my paid group, AI Automation

Society Plus. We've got over 3,000

members who are building with AI every

day and building businesses with AI. So,

it's a great place to be if you have

similar goals. But if you guys enjoyed

the video or you learned something new,

please give it a like. It definitely

helps me out a ton. And as always, I

appreciate you guys making it to the end

of the video. I'll see you on the next

one. Thanks, everyone.

So, we are just absolutely cruising

through this course. I'm having a lot of

fun. Hope you guys are, too. Now, since

we have all these new skills and all

this new knowledge, we're going to get

into how can we actually like make money

off of this or kind of start a business

off of this. So, we've got a couple

things to talk about. We're going to

talk about the mindset of actually being

kind of like an AI consultant or an AI

service provider. I'm going to talk

about how you can think about getting

some clients even if you don't have a

big YouTube channel or a big audience.

And then we're going to talk about

actually sort of like deploying and

handing over these solutions.

If you want to make money with AI, you

need to stop selling AI agents and

workflows and start selling AI

solutions. And I'm not talking about AI

operating systems or regular

automations. I'm talking about

diagnosing problems that businesses face

and then using AI to solve those

problems. So, in this video, I'm going

to break down why selling agents isn't

enough. what to sell instead that will

actually make you money and how to do it

yourself step by step. So, why are you

guys all here watching this video?

Because AI has exploded. And with that

explosion comes hype. Tons of people

throwing around buzzwords like agents

and workflows. And what's funny is

automation has been around forever. It's

nothing new. When I was working

full-time at Goldman Sachs in business

intelligence, [music]

automation was my entire role. And that

job had existed for years. But the

majority of small and mid-size

businesses, hardly any automations in

place. The difference now is that

because you slap the word AI in front of

it, suddenly business owners are paying

attention. It's like putting a neon sign

on an old restaurant, the food hasn't

changed. It's nothing new, but suddenly

people are noticing it. And here's the

thing, most beginners get this part

wrong. They get caught up in the tech,

the nodes, the HTTP requests, the multi-

aent architectures. They're so focused

on the shiny parts that it causes them

to forget what actually matters to

businesses. [music] And I've definitely

got carried away with this, too. In

fact, my best performing YouTube videos

are the ones that are really flashy and

have multiple agents [music] because it

was trendy and cooler. But if you were

to ask me which YouTube builds have

actually been the most practical and

highest ROI, it would be some of my

lowest performing videos. When I sold my

very first $1,200 workflow, I didn't

walk in saying, "Hey, I got this build

with 15 nodes and an API call to blah

blah blah." I said, "This will save you

hours every single week on content

creation." And that's what made it a

no-brainer. And here's the truth.

Businesses really only care about three

things: time, money, focus. That's it.

They don't care if you deliver it with

AI or a VA or duct tape and chewing gum.

Think of it like a taxi ride. If you

need to get across town, you don't care

if you ride in a Prius, a Tesla, or a

horsedrawn carriage. Well, I suppose

some of us may, but that's beside the

point. You just care that it gets you to

your destination fast, cheap, and

without stress. Businesses feel the same

way. They don't fanboy over AI itself.

They fanboy over the outcomes. That's

why AIcentric selling doesn't work.

Selling agents or workflows as products

is already a crowded commoditized

market. You've probably seen people

offering entire libraries of end

templates, claiming that you can resell

them all for $5,000 a month. yet they're

only charging you $200 to access that

bundle of templates. Why? Because it's a

race to the bottom on price. Take

LinkedIn outreach bots as an example.

You could build the flashiest, most

complex bot out there, but if you just

pitch it as a LinkedIn outreach agent,

nobody's going to care that much. But

when it is framed as a system that helps

you generate qualified leads without

spending on ads, suddenly people see the

value and they want it. The shift is

simple. Stop selling AI tools and start

selling the outcomes of those tools.

Spotlight the pain. Frame the solution

around time, money, and focus. And

that's how you win. And that leads us

right into the next section. What should

you actually be selling? AI solutions.

The difference is an AI workflow is just

a tool. But an AI solution is a tool

that's directly tied to solving an

actual business painoint. When you pitch

a solution, you're not saying, "I'll

build you a chatbot." You're saying,

"I'll cut down your customer support

workload by 60%. I'll automate your

client onboarding so you save 10 hours a

week." Or, "I'll help you create AI

assisted content so you can slash

marketing spend by 30%." [music] And

just to get it to stick, I'll throw one

more terrible analogy at you guys. Think

of it like medicine. If you have a

headache, most people don't care whether

you prescribe Advil, Tylenol, or an

herbal remedy. They just care that their

headache goes away. The pill is the

tool. The outcome is pain relief. That's

exactly how businesses see AI. So, the

framework we're going to be talking

about today is to diagnose, then solve,

then value, then price. And it's a

simple process that I use every time.

Diagnose means find the pain point.

Where is the business leaking time,

money, or focus? Solve means build the

system that fixes that exact pain.

value. Translate that fix into numbers.

Hours [music] saved, dollars saved,

revenue gained. And finally, price.

Anchor your offer around that value. And

when you think about that framework and

you think about the core problem that

you're trying to solve, you can see how

reselling a bundle of 20 end templates

doesn't really do that. So, let's take a

look at an example. Automating client

onboarding. First, we diagnose. Right

now, your team spends 5 hours a week

onboarding new clients. Then, we solve.

I'll build a system that can automate

80% of that. Then, we turn that into

value, which is 200 plus hours saved a

year at $50 an hour. That's $10,000 back

in your pocket annually. And [music]

then you price, I'm saving you 10K a

year. I'm only going to charge you 3K

right now. Suddenly, the price isn't a

cost. It's now just a fraction of the

value that they're gaining. Here comes

another analogy. Think of it like a home

renovation. If you're a contractor and

you walk into someone's house and you

say, "I've got the best hammer. I've got

the strongest nails, the fanciest saws,

blah blah blah. Nobody cares." [music]

But if you say, "This remodel will

increase your home's value by $50,000

and we can do it in half the time of

other contractors." Now you've got their

attention. The hammer doesn't matter,

the results do. This is why when I'm on

calls, I don't lead with, "Let me show

you my workflow." I lead with questions.

Where are you losing the most time in

your business? What processes do you

wish could run themselves? Because the

diagnosis always points me to the

solution. [music] And the solution

always ties back to measurable business

value. And when you get good at this,

you stop being just another automation

freelancer. You become the person who

can look at a business, spot

inefficiencies, and design solutions

that save them time, money, and focus.

That's the shift from becoming an agent

seller to a solution seller and being

seen as an AI expert or an AI partner.

So, you know why selling AI doesn't work

and that you need to sell AI solutions,

but how do you actually do this for

yourself? Step by step. That's what

we're going to cover now in a few simple

steps. And remember, we're going to tie

everything back to that same framework

that we just talked about. Diagnose,

[music] solve, value, price. Okay, so

step one, pick a niche and diagnose the

landscape. The goal here is simple.

Choose one group so that problems repeat

and your wins compound. Spend 10 minutes

deciding whether you'll serve agencies,

real estate, e-commerce, coaches, local

services like dental or HVAC, SAS

startups, whatever you want it to be.

Run your pick through these quick

filters. Do they repeat processes

weekly? Can they say yes and pay fast?

And do you already speak their language

through content you've made or past work

or interests? [music] When you think

about repeatable pains, picture agencies

struggling with lead qualification,

client onboarding, reporting, and

content ops. Real estate teams juggling

inbound lead triage, showing

coordination and document collection.

E-commerce brands needing CX ticket

deflection, returns automation, product

content, and ops reporting, or coaches

begging for application filtering,

calendar triage, and content

repurposing. The outcome of this step is

just to have a short list of niches that

you're confident enough to carry into

this next step. Step two, talk to five

to 10 businesses and diagnose pain.

Treat these as informational interviews

that could often turn into discovery

calls and paid work. I like opening with

a simple message. Hey name, I'm mapping

the top drains in X niche. In 15

minutes, I'll try to quantify your

biggest bottleneck and share where AI

actually helps and where it doesn't. No

pitch unless you ask. I'm genuinely just

trying to learn how I can provide value

to businesses. On a call, I would then

use the LRP framework, the listen,

repeat, poke. This basically means that

I listen while they describe their week

or their processes. I repeat back the

pattern to confirm alignment and then I

poke to quantify it. So, let's say the

business owner is talking to me about

some onboarding and reporting flows and

I find out that it eats about 6 to 8

hours a week. I would then poke back

with a question like, "Whose hours are

those? What's their hourly value? How

often does this process result in an

error?" You could also talk about money.

Where are you paying people to copy and

paste or chase info? You could talk

about focus. What interrupts you the

most between 9 and noon? You can talk

about errors. Where do mistakes cause

rework, refunds, or churn? And finally,

you could talk about a trigger. If I

could remove one weekly fire, which one

changes your week? The outcome of this

step is to have a ranked list of actual

business pain points with rough numbers

associated with them. Those numbers

being hours, cost, [music]

frequency, mistake rate, stuff like

that. We can then take that list and

move into step three, which is building

one simple solution and solve. Once

you've diagnosed a clear problem,

prototype the fix. And notice how I just

said prototype. This doesn't have to be

a perfect production ready system. It's

a P or a proof of concept that shows

that you understand their world and it

proves your technical expertise. This

doesn't mean you have to dedicate an

entire week to it. Here's how you can

spin one up in an hour and a half. Spend

about 15 minutes drawing the flow. Now

that you understand the process, just

map out the trigger, the steps, the data

sources, the outputs, and a clear

definition of done. Spend the next hour

doing a rough build on one platform like

Niten in so you have something real to

click through and demo. And then

finally, use the last 15 minutes to

record a quick 3minute loom that walks

through the before, the actual solution

itself, and then the result. And make

sure you have your camera on because

people want to hire people, not faceless

screens. [music] This is exactly why my

not so fancy LinkedIn workflow felt like

magic to that first client because it

removed the pain of ideiation research

and writing. And it didn't need to be

super fancy to do that. So avoid the

classic traps. Don't drift into multi-

aent fantasies. Don't stitch together

five vendors just to try them. And don't

start building a platform when the job

is just to fix Tuesday's bottleneck.

Just try to take a step back and think

about the actual problem you're trying

to solve. Because a lot of times you may

not even need like a very custom nit

agent. Sometimes there's already a

platform out there or sometimes [music]

you can do it already naturally in

someone's CRM. Don't overengineer. Just

be resourceful and solve problems. The

outcome of this step is that you now

have a demo video that you can send to

some of your other nurtured leads to

show them how you can solve their

[music] specific pain points. Next is

step four, which can trip up a lot of

beginners. This is turning your solution

into a price. And the easiest way to do

that is to translate what you built into

plain math that a business owner can

understand and relate to. Here's how I

explain it on calls. First, you have to

figure out how much time the process

takes today. Hopefully, you already did

that earlier in step two. Let's say a

team spends 10 hours a week on client

onboarding. Then ask what those hours

are worth. If the average employee is

paid $25 an hour, that's $250 a week.

Multiply that by 4 weeks to get a month

and suddenly the process is costing the

business around $1,000 a month or

$12,000 annually. Now, let's say you're

only able to automate 60% of that

workload. That's still $600 saved every

single month. Over the course of a year,

that's more than $7,000 back in that

business owner's pocket. So, when you

turn around and say, "Hey, I'm only

going to charge you $3,000 for the

solution." It's not an expense anymore.

It's an investment that has a very

clear, measurable return that already

pays for itself in 5 months, and it

keeps saving more money every single

month after that. And that's how you

make it a no-brainer. And of course, you

have to remember that value doesn't

equal time. The client's not paying you

for how long it took. When I built my

very first workflow for $1,200, it only

took me about 2 hours, which is $600 an

hour, which is a crazy rate. But once

again, the client wasn't paying me for

the hours. they were paying for the

outcome, which was saving [music] them

hours of content creation every week.

Finally, make sure to keep your scope

clear and simple. Write down the

objective, what's included, what's not

included, the timeline, [music] what's

expected from the client, the payment

terms, stuff like that. This avoids

confusion, ambiguity. It protects you

from scope creep, and it makes you look

professional. The number one biggest

mistake that I made when I was starting

off was underscoping and then having to

deal with all of this ambiguity. So if

you can make your proposals as specific

as possible and saying these 10 things

are the exact functionality of the

system, this is exactly the definition

of done. Then you're really going to be

protecting yourself and thanking

yourself later. So to recap, the formula

is dead simple. Figure out how much time

and money the process is costing now.

Build a PC and show how your solution

cuts down that time and money. And then

price your project at a fraction of

those yearly savings. Businesses will

pay happily when that math makes sense.

All right, moving on to step five, which

is to stack proof, build confidence, and

then scale. I'm going to be honest real

quick. When you're starting, imposter

syndrome is normal. You're going to

wonder if you can deliver and whether

the client will be happy. I felt the

exact same way. When I started working

with clients, I wasn't even calling

myself an expert. I was just curious,

building for fun, sharing things online,

and clients started reaching out. At

this stage, I would have been happy to

do work for free just to get experience.

And the fact that I was getting paid was

a big bonus. And if you're stuck with

that worry, you have two great options.

The first one is to do free or very

cheap work in exchange for proof. Say,

"Hey, I'll try this build out for you

for free. Either way, the system will be

yours. I just want to see if I can help

create something valuable for you and

your business. This removes pressure and

lets you optimize for reps, not money,

which is exactly what you should be

doing when you're starting off because

the testimonials and case studies and

confidence that you're going to gain are

worth far more downstream than a quick

$1,200 today. And those first three to

five projects really should be just

thought of as paid practice. They exist

[music] to teach you the process, give

you those case studies, and provide

proof. Your other option is if you'd

rather not do it for free, just offer a

money back guarantee. say, "Hey, if

you're not happy with it when I deliver

it or it doesn't deliver the value that

we discussed, you'll get all your money

back." That flips the risk, creates a

stress-free environment for you to learn

and experiment and still gives the

client a fair outcome. This matters

because in the early days, once again,

you're optimizing for experience, proof,

reps, not money. [music] And once you

have all that confidence, you can

actually move from being a freelancer to

a consultant and eventually get larger

and larger builds and larger and larger

contracts. Over [music] the past year,

we've been working on projects that have

ranged anywhere from $1 to $2,000 all

the way up to $30,000 plus. [music] And

none of that would have happened without

the low stakes project that built up my

confidence and portfolio, which let me

comfortably charge more and more every

time we sculpted out builds. And

honestly, I still think a lot of our

projects we've undercharged, but that's

a conversation for another time.

Anyways, once you have those first wins

under your belt, make sure you're

collecting that baseline and after data.

So, your hours saved, your errors

reduced, your money saved, [music] and

then turn them into simple case studies.

Of course, you want to ask for

testimonials and referrals and then

rerun the framework with new prospects.

But now that you have proof in hand,

it's going to be a lot easier because at

that point, you're no longer saying, "I

think I can help you." You're saying,

"I've already helped three businesses

just like yours. Here's the proof.

Here's the results. You want me to do

the same for you?" And that's when the

imposttor syndrome fades because the

market is actually validating that what

you're doing is working. And that's

pretty much the full loop. Diagnose the

problem, solve it with a simple system,

tie it back to business value, and then

price accordingly. From there, you stack

up your proof until you can scale with

confidence. If you want to succeed at

selling AI, you've got to leave your

obsession for technology behind and

think purely about the customer, aka the

business that you're selling to. So, I

know that was a lot of information.

Tried to make this one as valuable as

possible. What I'm going to do is have

all of this condensed into a resource

that you guys can access and look at

later. I will put that in my free school

community. Once again, completely free.

The link for that will be down in the

description. And if you found this video

helpful and you're looking for a full

course pretty much just like this, then

check out my plus community. The link

for that's also down in the description.

We just dropped a full course in there

called oneperson AI agency. So you'll be

able to get a formal course material

that goes over starting your oneperson

AI agency from scratch. And the great

thing about that community is we have

over 2,000 other people who are also

trying to do that exact same thing. So

it's a great space to meet people

potentially a business partner and maybe

even make a few hires in there or pick

up your first couple gigs.

People keep telling me they can't land

AI clients because they don't have a

YouTube channel since I got my first

clients through content. But you don't

actually need content at all. If I lost

my YouTube channel tomorrow and I had to

start from zero, there are three simple

ways that I'd get clients fast. And I

hardly see anyone talking about the

third method. So in this video, I'll

show you real proof that you can land

clients without a YouTube channel and

the exact [music] three steps you can

follow to sign your first few clients

this month. So let's get into it. So

just to start off, I'm not going to

pretend that YouTube or content doesn't

help. It absolutely does because when

someone watches a ton of your videos

before reaching out, they already have

trust and they've heard your voice.

They've seen how you think. And by the

time they book that call, they're

basically sold. And that's the power of

content. But what most people don't

realize, the agency that I founded and

exited, True Horizon, scaled past 100K a

month. And even though the majority of

our leads were coming from YouTube,

that's not where our best clients were

coming from. The clients we ended up

actually working with were the ones who

paid well, stuck around, and were a

dream to work with, came from two

things: referrals and partnerships. So,

we'd make one client happy and then

they'd tell their network or we'd

partner with tools or other businesses

that already had demand that they

couldn't service themselves. And that's

where the real growth came from. So,

yes, content is one path and it's a

really great way to build momentum, but

it's not the only path. And I get it

because I know a lot of you guys don't

want to start a YouTube channel or don't

want to be consistently posting on

LinkedIn every day. You don't want to be

on camera. You don't want to wait 12

months to see results. And that's

totally fair. So, we're going to talk

about three ways that you can land

clients without posting a single piece

of content. Starting with number one,

which is cold outreach. Now, before I

get into this, I need to be real with

you. Cold outreach is brutal when you

have zero proof. The first thing that

any prospect is going to ask you is,

"Who have you done this for?" And if

your answer is nobody, you're fighting

uphill the entire conversation. So

before you go off and send a bunch of

cold messages, go get some proof. Even

if it's small, even if it's free, even

if it's for your cousin's salon, the

product doesn't need to match what you

eventually want to sell. All that

matters is that you can say, "Yeah, I

have done this before. I've helped X

business get Y result." That alone

separates you from everyone who's purely

theoretical. So there are four

components to cold outreach: platforms,

finding leads, reaching out, and then

volume. So let's start with platforms.

For B2B, here's where you should be

looking. LinkedIn, Facebook groups,

email, school communities, YouTube

channels, Instagram, Reddit. Cold email

has an average response rate of 1 to 5%,

but personalized emails see up to 17%

higher rates. LinkedIn inmail DMs have a

10 to 25% response rate compared to

email, which is much lower. But the

LinkedIn DMs require more time per

message. So, I wanted to just throw

those stats at you, but pick one or two

to start. Don't try to do outreach on

all of those platforms. You're going to

spread yourself too thin because they

all have different methods of what works

best. So, once you've picked your

platform, here's where to actually find

people worth reaching out to.

communities in your niche, followers of

relevant pages or creators, business

owners already complaining about wasting

time or making mistakes, job boards and

comment sections because if someone's

hiring for a role you could automate,

that's a signal. You could also look at

local businesses in your area. Pro tip

though, before you jump into something

like Apollo or LinkedIn Sales Navigator

to find a lead list, spend 10 minutes

asking CatchBT or Perplexity where

industry specific directories exist. So

like architects have the American

Institute of Architects, coaches have

coaching directories. Every industry

probably has something and these

databases have already been filtered for

you. Now when it comes to reaching out,

keep it simple. Focus on of course the

problem, the outcome, not the actual

tech solution. Nobody really cares if

you built an 18 node automation with an

end and Slack and notion MCP. They care

about the results, which is, you know,

more leads, less manual work, fewer

errors, faster turnaround. Short value

focused messages work better than long

pitches. Your goal is not to close them

in one message. That's just not

realistic. Your goal is to get them

curious, to start a conversation, get

them wanting more. That's why the

subject line is so important because if

they're not curious at all, they're not

going to click to open the email. Now,

here's something, and I know it sounds a

little bit counterintuitive, but just be

completely honest about where you're at.

That's my approach at least. So, saying

something like, "Yeah, I'm just getting

started. I'm trying to start up a

business." And that doesn't undercut

you. It actually creates like a pattern

interrupt and it builds trust because

the prospect thinks, "Okay, this is

actually a real human." Instead of,

"Wow, great." You know, another faces

pitch of someone trying to sell me. And

of course, because you're unknown and

unproven, you want to remove all the

risk from your offer. So, no payment

until results, no contract. The only

thing that you ask for is permission to

use them as a case study if the solution

works. You're not asking them to trust

you and give you a ton of money. You're

making it a no-brainer for them to say

yes. And then one more thing, asking a

stranger for 30 minutes on their

calendar is a big ask. People are busy.

People don't want to hop on calls with

random people just to be sold. So,

instead, get them curious. Again, ask

them if you can send them a 2-minute

Loom video explaining the offer. and

then you can record a quick video

walking through how you'd help their

specific business and let them do the

heavy lifting before they ever get on a

call with you. All right, the numbers

game. So, in the wise words of Alex

Ramosi, someone I've actually had the

pleasure of meeting multiple times,

volume negates luck. So, if you want to

guarantee clients, you just need to

increase the volume. At the very least,

you should be sending 100 messages a

day. I know that sounds like a lot, but

understand this. A small percentage of

replies is actually a really good

metric. So, we talked about the 1 to 5%

average with cold email. If you're doing

anything above 5%, you're crushing it.

Which means if you send 100 emails and

you only get five people to respond, not

book in a call or pay you, just respond,

that's actually really good. But you do

need to track everything. Your reply

rate, your positive responses, your

meetings booked, your deals closed. Each

metric tells you what area you need to

improve. And you don't just track the

wins, you also have to track all of the

negative responses because that tells

you what not to do. So when you get

positive replies, you write down the

company size, the industry, the job

title, anything else that's relevant.

And then you can start to build your

future lead lists around those patterns.

And this is how you actually

systematically improve instead of just

guessing. Now, here are the two things

that most people do get wrong with cold

outreach. The first one is maybe just

don't build before you sell. If you're

spending weeks perfecting an automation

before you've talked to a single

customer, you don't have a business, you

just have a hobby, you need to use cold

outreach as market research. Create an

offer around something that you could

build that you know it's feasible and

then send messages about it. See if

anyone bites. If they do, and you see

market validation, then go build it. But

don't build before you sell. Once again,

if you're spending all your time

building something that no one's going

to buy, there's just no point. So the

second one is to start small and then

reinvest. You don't need massive email

infrastructure with thousands of

domains. You just need a few and each

domain can send about 30 messages a day

and that's enough to generate real data.

Once you close your first deal, you

reinvest that money into scaling up your

outreach. And look, the thing is people

will ignore you. People will tell you to

screw off and that's normal. Most people

quit because of that emotional weight

and how tough it is to do cold outreach.

So just understand that and don't take

it personally. Use it as data and then

if you can push through, you're already

ahead. If you guys are interested in

diving deeper specifically on cold

email, then I just did a podcast with

Savon, who was able to generate over

half a million dollars in sales

opportunities with cold email in 6

months as a beginner. So, I'll go ahead

and link that right up here. But

anyways, that is cold outreach. So,

let's talk about method number two,

which is referrals. So, why do referrals

work so well? Simple, because business

owners trust recommendations way more

than strangers. And that's not even

about business owners. That's just

people in general. Think about how many

times your friend has told you about a

great restaurant or a TV show. You're

way more likely to go check it out than

if you saw an ad or a review for it

because you trust your friend. In fact,

92% of B2B buyers trust referrals from

people that they know. And being in the

AI space, it's really good to lead on

referrals because it's very new right

now and a lot of people are thinking,

you know, I don't even know where I

could go find a vendor to help me out

with this problem. Business owners want

to know that someone that they trust has

already taken the risk and it worked out

well for them. When I first started

freelancing, I'd make it a priority to

overd deliver for the client. So maybe

that looks like adding a simple

dashboard that they didn't ask for or

creating full documentation so that they

could understand how everything works

and they can maintain it if they choose

to. Then, and only then, I knew they

were happy. Usually after we'd been

working together for a while, I'd whip

out the golden question. Hey, do you

have any friends or know any other

business owners who might need AI

automation or might just be interested

in talking to me about this kind of

stuff? You don't need a fancy script or

a formal incentive program. Just a

simple question after you've earned the

right to ask. Happy clients want to

share. Think about how many times that

you've wanted to put on a friend to a

new restaurant, a new song, or a new

product. People typically enjoy telling

other people about things that worked

for them. So, if you've done great work,

they'll probably want to brag about it.

But the timing really matters because

obviously you can't ask for referrals

until you know that they're happy and

that they have to truly believe you did

provide them value. So typically I'd

wait about a month or two after

something's been like pushed live. And

ideally you'd want to tie that into a

moment where you can show them results.

So maybe you're doing a month one

performance review. So you would

obviously say you know like hey when we

started here are all the KPIs and the

metrics that we had documented and

here's what we were going to track and

now after 1 month of the solution being

in production we've hit all of these

KPIs and your business has grown you

know x amount. The project has been a

success. And then once they actually see

that data, you can ask about, you know,

the golden question. The conversation

then feels a lot more natural because

you've just reminded them of the value

you delivered. It's not awkward. It's

not like you're trying to sell them

again. It's earned. Now, you could

absolutely set up like a formal referral

structure if you want, but honestly, a

lot of times you don't need anything

formal. Just do great work and then ask.

Now, here are the common mistakes I see

when people are trying to get into like

the referral game. The first one is

asking too early before you've actually

proven yourself. And then the second one

is not asking at all and just leaving

that money on the table because you were

too scared to ask. According to Dale

Carnegie research, only 11% of

salespeople are actually asking for

referrals. Yet, 91% of customers said

that they'd gladly give one if they were

asked. So, make sure you are asking for

referrals. They will lead to bigger

projects. They'll lead to longerterm

clients, and they'll be way less

friction than doing cold outreach. And

once you've got clients that you're

working with for longer term, it opens

up method number three. And honestly,

this is the one that I'd be going allin

on if I was starting from zero. I call

it the Trojan horse method. The big idea

here is that instead of trying to build

trust from scratch with cold prospects

and build up all of your own authority,

you borrow someone else's. You borrow

their trust, you borrow their authority,

and you borrow their existing client

relationships. Partner source deals

close 46% faster than other deal types.

So, think about it like this. Marketing

agencies, consultants, coaches, law

firms, they already have clients who

trust them and have maybe been working

with them for years. They've already

built those relationships. And right

now, a lot of those clients are

thinking, I need AI. And the agency

itself is probably thinking, I need to

be able to offer AI to my clients. So

instead of competing for their

attention, you partner with people who

already have it. So here's what you

could say. Hey, I help businesses

implement AI automation. I'd love to

offer free AI discovery calls to your

clients. No cost to you, no cost to

them. You get to look like a hero

because you brought in an AI expert and

you gave them free value. And if any of

them end up wanting to work with me,

I'll give you 20% of that project

revenue. There's essentially no risk for

them. They're not paying you. You're not

asking for anything from them upfront as

far as money. You're just saying, "Let

me make you look good to your clients."

So, this works well because when the

agency owner says to their client, "Hey,

you know, I'm going to bring in this

expert to give you a free audit." You

instantly have more authority. You're

being called in like a consultant.

You're the specialist that they are

introducing. Compare that to cold

outreach when you're a complete stranger

in an inbox trying to prove yourself.

So, with the Trojan horse method, you

borrow credibility from day one and

you're getting access into probably a

bunch of clients who already trust and

already pay and are already warm to

spending money on services. So, they're

not tire kickers. They're real

businesses with hopefully real budgets.

Now, when you are able to secure a few

yeses, just keep it simple. hop on the

discovery call, learn about their

business, understand their processes,

and tell them where AI could help them.

Now, if they hop in the call and say,

you know, like, "No, I need to use AI,

and I'm glad that we're having the

session, but I have no clue where to

even start. Tell me what I don't know."

What you want to do is help them

identify their current constraints. So,

a really good question you could ask is,

if tomorrow you've got 300 people that

wanted your services, what process would

break first in [music] that, you know,

customer life cycle? And then they'll

think about it. They'll run it through

in their head, and then they'll say

something, and you just dive in on that

process. And here's the best part about

the Trojan horse method. Even if they

don't end up becoming a client, I think

it's still a win-win. You got experience

doing a discovery call. The business

owner got free insights about AI, and

the agency looked like a hero for

bringing you in. Win-winwin. And some

percentages of those calls will turn

into paid projects. Remember, it's a

numbers game. You need to do 10 times

more than you think. Finding partners is

the same process as cold outreach.

Building a lead list of agencies,

consultants, and service providers, and

niches that you want to work with reach

out with an offer that's hard to say no

to. And luckily, that's kind of what

this method is. It's an offer with like

zero downside for them unless you mess

up the discovery call big time. And

that's basically the risk that they

have. But of course, the upside is

they're providing tons of extra value to

their clients and they might get 20% of

a big project. So if you construct that

offer and you hit their inbox or their

LinkedIn DMs, most agency owners will

actually at least hear you out. So

that's the Trojan horse method. Borrow

trust, make partners look like heroes,

get in front of warm clients without

building your own audience. So now that

we've talked about those three methods,

let me give you a road map. But first, I

need to do one thing. I need to flip how

you're thinking about this. A lot of

people think about this backwards. They

spend weeks, maybe even months, building

out elaborate systems, perfecting every

deal, and then they try to sell it. By

that point, they've invested all this

time into something that they have no

idea anyone actually wants. There's no

market validation. So, the smarter thing

is to actually flip that order and

create an offer around something that

you know you could build. Maybe you see

other people building it, so you know

it's possible. And then start sending

outreach as if you have the thing built.

See if there's anyone interested. See if

people respond. If they do, then build

it out. But if nobody bites, then you

should pivot to something else and test

that offer again before you build it all

out. In that case, the only thing you've

lost is a little bit of time that it

took to write some of those messages.

But the lesson is stark. You can have

the most technically impressive system

in the world. But if you built it in

isolation without talking to customers

first, you just have an expensive

portfolio piece that nobody actually

wants. Cold outreach gives you direct

primary research from the market before

you commit to building anything. People

either respond or they don't, and that

signal is worth more than any amount of

guessing. So, now that we've covered

that, let's talk about the four-step

framework. Step one is offer first. So,

pick a niche, pick a problem, do some

research, create an offer around an

outcome that you're confident you could

deliver. Now, I do think that building

simple PC's and demos is fine and

probably a good idea just in case on

that Loom video you can show them how it

works or on a call, but don't pour weeks

and weeks into building something once

again if you don't know the market wants

it. Step two is validate with volume.

So, test it with outreach. Aim to get

five clients so that you can start

getting referrals and case studies. If

you're doing manual DMs on LinkedIn or

Instagram, maybe aim for at least 100 a

day. I know it's aggressive, but that's

what it takes to get real data fast. And

if you want to take the cold email

route, then definitely just invest in

some domains. Maybe you could buy

domains that are already warmed up and

get some inboxes that you can scale up

to like 500 emails a day. Cuz keep in

mind, even if you're getting a 3% reply

rate, that's still pretty good. But

here's what separates winners from

losers. Because both winners and losers

will fail. Everyone hits roadblocks. The

difference is that winners understand

why they failed and they changed

something. Losers keep throwing time and

resources into a broken system. So

monitor your data every single day.

Track your open rate, track your reply

rate, track your positive response rate.

If something's not working, then figure

out why and actually adjust it. Step

three is to deliver and then document.

So once you do land a client, your job

is to overd deliver and then track

everything. So before you start, you

have to get those baseline metrics. How

long does the process take manually?

What's the error rate? What are the

current KPIs? And then after your system

is live, you measure those same numbers

again. You show them the before, you

show them the after. And that does two

things. It first of all proves ROI so

they know it was actually a good

investment. And the second thing is that

it gives you a rockolid case study to

use for future clients. And then of

course, once you've shown them all that

data, ask for the referral. And then

step four is to scale with borrowed

authority. Now that you've got some

results under your belt, start using the

Trojan horse method. Reach out to

agencies, consultants, and service

providers. Offer to do free audits for

their clients. Make them look like the

hero. Take 20% rev share on any deals

that you close. This gets you in front

of warm leads without building your own

audience. And because you're introduced

by someone that they already trust, you

have instant credibility. So, I know we

covered a ton of information in this

video. So, what I did is I threw all of

this into a resource guide, which you

can access for completely free in my

free school community. Link for that is

down in the description. And if you want

to dive deeper into all this kind of

stuff and connect with over 3,000

members who are building their own AI

automation businesses, then check out my

plus community. The link for that is

also down in the description.

If you can build AI workflows, but you

still can't sign a client, then this

video is for you because I'm going to

show you how to land your first AI

workflow client in just 7 days. [music]

And this isn't theory. Christian used

this exact process and signed his first

client in just 5 days. So, in this

video, he'll break down what he did and

then I'll show you the exact same method

step by step so that you can copy it.

So, let's get into it. All right, guys.

Today I'm here with Christian. He's a

member of the community and he's had

some huge wins inside the community. He

actually got a client in the first 5

days of joining and going through the

program. So I wanted to bring him in

today and just kind of highlight his

story a little bit and talk about, you

know, some of his big breakthroughs and

how he was able to achieve these wins.

So Christian, if you want to give

everyone a real quick intro, a little

bit of your background and, you know,

how technical were you before hopping

into this AI space?

>> Yeah, so uh my name is uh Christian. I'm

uh 21 years old out here in Arizona. And

for me as a background, I've always been

kind of techsavvy, always liked doing

like using the tools. But as far as AI

itself, I was barely introduced this

year. Like it was back in March when I

was introduced. So still fairly new.

Once I got introduced, I just got

obsessed and just started rolling with

it. But started this about a couple

months ago. Loving the community, loving

all the support and all the guidance

with it. And it's just it's just been

great ever since I joined.

>> Awesome, man. Well, yeah. I'm super

excited to have you here today and just

get to talk about, you know, what got

you into this space and how you were

able to achieve, you know, these client

wins. So, I guess that's the first one

to start off with, like what actually

was it to you that made you realize

like, I want to take advantage of this

AI opportunity?

>> Once I started getting introduced to it,

getting more acquainted with it, I just

I love the possibilities and all the

different things that you can do with

AI. And for me, about it was about 3

months ago, I had that light bulb

moment. It was like what if I can

somehow use this in businesses and help

them do that and I can charge them a

whatever price but ultimately it'd be

solving a rich person problem. It was a

really cool moment really when I found

it. So

>> 100%. Yeah. So once you kind of found

out you wanted to go down the AI

automation space and I think n was was

your big tool as well. What were you

doing and like how were you trying to

find clients before joining the

community? Funny enough, um I actually

didn't start using NAN about up till

about a couple weeks ago. But before

that, my other community that taught me

a way to where we can scrape leads off

of LinkedIn, find their emails, generate

email bodies for them using AI and then

loading it into a website called

instantly AI where you can just in uh

emails like cold emails. It was a great

thought to begin with, right? It was a

great idea. I was doing a bunch of

emails, like 450 a day, but uh it was

like a crazy open rate, but nobody was

buying. Uh just a lot of shots in the

dark. Didn't really know how to

structure the emails. I I didn't know

how to write copy or anything. So, well,

I was basically just trying anything and

everything I could. Joining Facebook

group, talking to my contacts that I

have, other business owners, uh see if

they can I can do it for them or if I

can just if they have anybody that I can

do it for. Just really no proper

guidance or no, uh set direction. just

kind of shooting off different lanes

hoping that one of them was going to

hit.

>> I think the reason what like cold email

is really successful and cold outreach

in general I think once you're ready to

scale but like to get your first client

it's really tough to do that because

people are just like I don't know who

this guy is and it's like he has nothing

really to show me yet. Why would I kind

of give him or her my business? So how

did then your approach kind of change

once you were in the community and

started to you know interact with the

people in there in the course material?

>> Biggest one by far was how to position

myself. Right. We're not selling

workflows. It's the brand behind it.

Scale or get your time back, whatever

the goal is for your business.

Positioning myself as a proper guide,

not a template salesman. That was a

really key thing for my for me in my

process. And it's it's just it was black

and white difference and it helped me

out a ton. Within days of me doing that,

I posed my first client, which was

insane.

>> Yeah. Know, I was just looking at our

our DM on school right before we hopped

on and I remember, you know, you joined

the community. We we had a quick chat,

got you access to the course, and then 5

days later, you messaged me. It's like,

I just closed my client for like what

was it? Was it 1,500 or something like

that?

>> Uh yeah, 1500, 1500. And we actually we

upped it recently. So, we're doing uh

2,000 now. And then I think it's going

to over time build and build and build

from there as I get better, too. Yeah,

it was it was 1500 starting out. So, it

was it was pretty cool.

>> So, you made a post about that win,

right? And then I pinned it in the

community and then did you say someone

reached out to you from that post and

you got another client off that? So off

that first one, I was getting a lot of

praise or a lot of traction. I was like,

"Oh, this is cool." And then you know

the the gem as well. So that was that

was even better. Literally three days

later on that was that Friday I posted

that Sunday. Another member in the

community reached out. He was a newer

member and said, "Hey, I'm looking for

to hire uh he called it an AI automator.

Um and then it went from getting, you

know, got the first client, engaged with

the community, got the second client,

and now I'm able to actually do this

full-time and not even have to worry

about work." So, which is great.

>> Um, and it sounds like your kind of

biggest light bulb moment so far from

the community has been just the idea of

the way you position yourself and um,

probably how you conduct yourself on

those initial discovery and sales calls.

So, is there anything specifically you

can think about where you know hopping

on discovery calls or trying to talk to

business owners before having that kind

of like light bulb moment, the way that

you would like speak about AI or speak

about automations has shifted?

>> Yeah, definitely. Uh, before I would I

didn't really I didn't have a process. I

would walk in there and say, "Hey, this

is what I do. I can build template for

you if you need and it can solve this.

Do you want it? And that was that was

kind of it. But going through the uh

lessons and actually showing all right

this is how you should ask the

questions. This is how you find the pain

and find ways that we can actually

leverage AI to actually help their

business and and again I'm an actual

guide in their process in a in the

journey of AI cuz it's it can be very

overwhelming. So once I started

positioning myself there it was a

complete 180. Yeah. It was just it was

yeah complete night and day difference.

I'm going to do that with all my

processes moving forward. But that one

specifically really helped me out a lot.

>> So besides the the way that you shifted

your perspective as far as like you know

let's think about your business and let

me help you diagnose problems rather

than just here's a template. What else

do you think it made them say yes?

Because at this point there's there's

this mental battle of like how much

should I charge or should I do it for

free or like what what proof do I

actually have? How do I get someone to

say yes? So, what else do you think it

was about you and about the way that you

spoke to this this person that got them

to ultimately give you their business?

>> Well, for the second client, I mean, he

kind of knew my situation a little bit

cuz he saw the post, he read it, and

then that's when he reached out. I was

just very very honest with them and

upfront about like, listen, this is um

obviously you know the value of the

product. So, uh, I went in there, I was

very, very open. I was very honest and

transparent about me, where I'm at on my

journey and my goals for him and was

mainly just trying to focus on building

that relationship.

>> Yeah. And now, I mean, the rest is

history. So,

>> yeah, it's awesome because now that your

foot's in the door, there's so much

opportunity for for more growth and and

for bigger projects. And I've always

said, you know, you'd rather have one,

let's just say 10K a month client rather

than having five 2K a month clients. You

just have an opportunity to go way

deeper. And that just leads into better

referrals, better case studies, more

opportunities to win more business,

things like that. Do you want to walk us

through the actual solution that you've

provided to this first business or that

you're working on and and also how you

got to that price point and what sort of

like that conversation looks like?

>> The one that I built, so I was trying to

build a system for updating clients. A

huge pain point that we were having

simply just communication. Like a lot of

clients would call up like, "Hey, uh,

what's this? I don't know what they mean

by this. when is this going to get

scheduled? Or nobody's talked to me.

Nobody's reached out. I don't know

what's going on with my project or

sometimes they're just simple FAQs. They

just want to know, hey, what what is

shot create? And they can simply Google

it, but they're going to call us first.

I focus on building a workflow for that.

And it actually I got inspiration for it

from one of your YouTube videos.

Actually, it was your AI assistant. So,

I took that kind of blueprint and used

it to build out a I called it like a PM

assistant. So when the project manager

is out on site, he can just simply talk

to the bots, it'll, you know, engage

with him, do what and execute whatever

tasks are needed, whether it's sending

clients an update email, logging an

update into the CRM, little things like

that. He loved it. He completely bought

in. Uh I'm still improving it to this

day. It's not perfect yet, but it's um

it's constant refining. We're meeting

every week to get it better and better

and better, but that's the one I started

with.

>> I want to ask you now compared to let's

just say 3 weeks ago, how much more

confident do you feel? and just your

ability to talk to people, show them the

value, deliver on solutions, price your

work, all that kind of stuff.

>> A lot more confident. Before I had no

idea how to do any of that. I was just

kind of got to go kind of go in and just

give like a set base price point for

whatever workflow that I build. Um, and

again, before I was just trying to sell

templates basically. Now I feel a ton

more confl confident knowing what my

offer is. um having a clear offer for

them that they can understand and being

able to properly communicate what it is

that I do and how it can benefit their

business.

>> That's awesome to hear, man. I mean,

it's a cliche, but it's so true. Just

the idea of like surrounding yourself

with like-minded people, like what that

really does to you, because I know like

right before we started recording, we

were just talking about how there's just

so much noise and there's so much great

education everywhere. But when you get

stuck in that world where you're just

watching, watching, watching, and you're

getting like a scattered bit of

information, and you don't have like a

structured path, it just makes it very

overwhelming, of course, but also

confusing.

>> Yeah, man. I wanted to kind of close off

here if you've got any any final

thoughts or where could people find you

if they want to get in touch with you?

>> Um, yeah. Yeah. I mean, it would just be

uh my LinkedIn mainly cuz I don't really

have a website right now or through the

community. I think that's the the best

way possible. I'm in both of the

communities, regular one and then the

plus community as well. I'm mainly in

there more than anything [laughter] I

would say. Just doing the same thing,

just connecting with people, trying to

provide value, and then seeing what else

that I can learn. So,

>> it's really inspiring to hear your

story, man. 21 years old, started less

than a year ago in this space. And and

you guys also just heard him say

basically doesn't have a website yet.

He's new. He he told clients, "Hey, I'm

new. I'm learning, but I want to help

you." And he's been able to secure some

pretty crazy wins. So, hopefully that's

all very motivating to all of you guys

that are watching this that are trying

to get to a spot where where Christian

now is. So, thanks so much for coming on

today, Christian. I really enjoyed

getting to know you and and getting to

hear a little bit about your journey.

Yeah, just keep crushing it. Best of

luck, man.

>> Thank you, man. I appreciate it. I'm

going to try my best.

>> So, now let's look at the exact method

that I gave Christian that landed him

his first client in just 5 days. By the

end, you'll have everything that you

need to go sign your first AI client.

All right. So, before I walk through

that actual 7-day plan, I just want to

slow this down and ground it in what

actually happened with Christian because

this is where most beginners go wrong.

If you think back to what Christian was

doing before he joined the community,

it's exactly what I see almost everyone

doing when they get started, which is

high volume, tons of cold outreach with

no soul and no positioning, using tools

or automations to scrape LinkedIn,

pulling emails, using AI to write

generic copy, loading it all into

instantly, and then blasting out like 4

or 500 emails a day. Now, on paper, this

feels really productive because you're

sending out so many messages. But in

reality, you're just another random

person who's selling AI templates with

no proof, no trust, and no real

connection. And at that point, you're a

commodity. And when you're a commodity,

it turns into a race to the bottom on

price, and you'll almost always lose.

Because there's always going to be

someone out there who will offer your

service for a cheaper price. So, what

changed everything for Christian was not

better tools or more automation. It was

the mindset shift. He stopped thinking

like someone who was trying to sell

workflows and started thinking like

someone who was leading with outcomes.

He positioned himself as a partner, not

a template salesman. So, instead of

saying things like, "Here's what I

built. Here's this automation. Here's

this template I can, you know, customize

for you," he was saying, "Here's how I

can help your business do X." And he was

targeting a specific painoint. So, that

one shift is the entire reason that this

worked in 5 days instead of never

working at all. Now, before we get into

the 7-day plan, I want to talk about

three psychological hurdles that

everyone goes through. I went through

them. Christian went through them.

You're probably going through them right

now. And the first one is imposttor

syndrome. Everyone will feel this at the

beginning. And honestly, I still feel

this sometimes right now. Thoughts like,

"Do I even have the right to charge for

this?" Or, "I don't want to feel

scammy." Or, "What if I'm not ready

yet?" And that feeling will never fully

go away. But you do learn how to work

through it. So, the key is just to not

overpromise because that's when you run

into trouble. Both Christian and I did

the same thing early on when we were

getting started. Literally saying, "Hey,

I'm new to this. I'm obsessed with it.

I've been learning a lot. I've been

building a lot and I want to help you

with this problem." And that type of

honesty makes you sound like a real

human. Like I said, especially early on

when you're doing your first one or two

clients for free or very cheap. That's

not a weakness. It's low risk for them

and it gets you experience, which is the

only thing that should actually matter

to you right now. Your goal should be to

overd deliver. Prove to yourself, and

also prove to the client that you can

actually do this. And that imposter

syndrome starts to fade because now you

have actual experience to talk about and

you have actual results that you've

driven. Now the second hurdle is about

pricing. People get stuck here way too

early. They obsess over retainers and

monthly pricing and they want to hit

that 10K per month figure that

everyone's going for. But if you're

trying to maximize revenue before you

even ever delivered value or got

experience, then you're going to fail.

So the thing that I want you guys to

lock into your brain is that trust comes

before retainers. Asking someone for a

retainer right away would be like asking

someone for a referral right away before

you even have any sort of partnership.

It's very hard to get someone on a

monthly agreement if they've never

worked with you before. So, what should

matter to you first is just delivering

value and earning trust and then you can

win a retainer later. That's why I

always talk about valuebased pricing.

And I made a full video on this and I'll

link it up there if you want to check it

out. But anyways, you want to get your

foot in the door, solve a real problem,

and clearly show the value that you

delivered. And once that trust is built,

then talking about a retainer becomes

super easy and much more natural. Like I

said earlier, the same rule applies for

testimonials and referrals. You can't

ask for those until you've actually done

something. So, don't think about a

retainer as step one. Think of it like

something that you've earned once you've

built a relationship. And the third

hurdle is just rejection. This one

scares people more than it should. When

you're new, you are going to get

ignored. People will say no. Some won't

respond at all. That's completely

normal. The important part is what you

actually do with that rejection. Every

rejection is feedback. It's more data

for you to learn from and win from

because the reality is everyone gets

rejected. So the difference between

winners and losers is that the winners

pay attention to why they were rejected

and they actually fix something. They

change something about it. And losers

just get rejected over and over and they

don't change anything. So if someone

ignores you, ask why. Was my message

unclear? Was it too long? Was it vague?

Did they even have a reason to want to

care to respond to me? And then you fix

that. And then your next attempt gets

better. Okay, so those are the three

hurdles. Now, let's talk about actually

breaking down the 7-day framework and

connecting it back to what Christian did

because this is where people tend to

over complicate things. So, the first

thing I want to make very clear is this.

Christian did not start by picking some

super ultra specific niche and having

every problem figured out and then

blasting out cold emails. He started

warm and that matters way more than

people think. warm outreach, referrals,

and known contacts are just

statistically shown to convert way

better than cold outreach, because

there's already trust there, even if

you're borrowing trust from a friend of

a friend. That's why it works so much

faster, and it feels way less awkward,

especially as a beginner. So, big

picture, the flow looks like this. You

start warm, you stay fairly broad, you

talk to people, you notice patterns, and

then you niche down later. Cold outreach

comes last when you're ready to scale,

not first when you want to get your

first client. So day one is all about

setting a loose direction. Not locking

yourself into one super hypersp specific

niche, but just think of it as like a

working hypothesis, not a lifelong

decision. So instead of saying, "I'm the

AI automation guy for dental clinics in

Georgia, losing time with onboarding,"

you're just going to say something much

simpler like, "I help small businesses

automate boring, repetitive tasks with

AI." That's enough to get conversations

started. At this stage, you should also

have a short menu of example problems in

your head, example use cases in your

head, so that you're not just speaking

in theory. So things like, you know, I

know how to automate lead follow-up or

intake forms or data syncing between

CRM. And like I said, you're not

committing to any of these yet, but

you're just testing to see what

resonates. On day one, you also want to

build what I would call a trust map. So

open up a simple Google sheet and list

out people where trust already exists.

Your goal for day one would be to write

down 20 people that you can reach out

to. Friends or family who run

businesses, past co-workers, managers,

clients, people who you know from

communities, Slack groups, Discords, or

online spaces, and the second degree

connections. So, friends of friends, for

each of these people, just note what

kind of business they're in or what kind

of industry they're in, how well you

know them, whether they could be a

potential client or an intro to one, or

just someone who can give you some

insight. And when you actually start to

write this stuff down and think through,

you know, your list of contacts, it

makes everything feel a lot less random

and a lot less overwhelming. Now, days

two and three are about having 5 to 10

warm, low pressure conversations. These

are not sales calls. You're not

pitching. You genuinely just need to

understand where repetitive work eats

time in their business or in their daily

workflow. So, when you're reaching out

to them, you should just sound like a

curious entrepreneur, not a salesperson.

So, something as simple as saying, "Hey,

I'm trying to start a business where I

help other businesses automate

repetitive work with AI. I'm not trying

to sell you anything. Could I just ask

you a few questions about where things

feel manual or annoying in your

day-to-day?" And once you start having

these conversations, write down all the

key insights from that call because

you're going to need to look at these

later. And if you truly cannot think of

anyone in your network who might own a

business or be an executive at a

business or in a position to buy or

anything like that, then you still don't

have to jump straight to cold outreach.

you just reach out and ask something

like, "Is there anyone you know who this

might be helpful for?" or "Is there

anyone you know who this might benefit?"

And so that little like wording shift is

huge because no one really wants to sell

to their friends and you're not selling

to your friends. You're just asking if

they know anyone who might benefit from,

you know, the kind of stuff that you're

talking about. It feels way more

natural, less uncomfortable, and it

still lets you kind of borrow some

trust. You also could jump on a site

like Upwork, but once again, that's

pretty much going to be similar to cold

outreach because you haven't yet built

trust with those leads and you're just a

name and a profile picture. So, after

you've had those conversations, day four

and five are where you turn those

conversations into a tiny pilot. So,

look back at your notes, pick the person

with the clearest, most painful,

repetitive task. You're looking for the

clearest pain point here. And then you

propose something very small and very

low risk for that prospect, which is

typically a free workflow. You build it.

You measure one simple outcome. And then

you decide together if it's worth

expanding. So, you can reach back out to

them after that initial conversation and

say something like, "Hey, I'd love to

build you a small automation that

tackles X painoint as a free pilot. My

goal here is just to prove that these

workflows actually can save you time.

And in return, I'd just ask for some

honest feedback because that's going to

help me learn and grow. Now, days five

and six are about actually building that

tiny MVP. So, this doesn't have to be

complex. In fact, the simpler the

better. Your goal isn't to impress them

with all of these API calls and all this

advanced tech. Your goal is just to show

them I saved you time. I saved you, you

know, confusion here. And while you do

this, just pay attention to the language

they use, how they describe the problem,

how they describe that win. The language

is gold later. Okay. Now, day seven is

where you see if your hard work paid

off. The goal of this day is super

simple. You're not trying to hard close

anyone. You're just trying to figure out

with the potential client what the next

logical step is based on how the pilot

went. So, the first priority would be to

see if you can keep helping that same

client, either by maintaining what

you've built, or by expanding on it

functionality-wise. So, you can lay out

clear, low pressure options. You explain

that there are a couple ways that you

could keep helping. The first option is

maintenance. This is you sticking around

to make sure that the automation keeps

working, handling fixes if something

breaks, and making small tweaks as their

tools or processes change. And the other

option is expansion. So, this is where

you build on top of what's already

working. Usually, by adding one or two

concrete features that you notice during

the build that would make the outcome

even stronger. The key here though is

just to communicate these two actual

offers very, very simply. So, a

maintenance offer could be like, hey,

I'll maintain this for the next few

months, so if anything breaks or if you

want small changes, I can handle it. And

an expansion offer might be, hey, we

could turn this into a slightly bigger

system by adding this and this so that

the result is x more reliable. And then

you can ask if they want to scope out

that and then you can send over a basic

proposal, nothing fancy. During this

conversation, you could also naturally

surface more work by asking thoughtful

questions. For example, you could say

something like, "Hey, while while I was

building out this workflow, I noticed

this other process that's related. Would

have helped if that was automated, too.

Or now that you've seen what this

workflow can do, what's the next thing

that you would like to get off your

plate?" These types of questions show

that you are a partner and that you're

keeping things collaborative rather than

being salesy. And then, if they're happy

with the pilot, but they don't

necessarily want to continue working

with you right now, that's completely

fine. At that point, your goal is to

just lock in some proof, not push more

work on them. So, you can ask if they'd

be open to a short video testimonial

explaining how the workflow helped. Only

after that, and only if it feels

natural, you can then mention if they

ever think of someone that might also

benefit from AI workflows like this,

then an intro would be super

appreciated. But, of course, if the

pilot did not go well, you don't try to

sell anything. You don't ask for a

testimonial. You just take that

feedback, you learn from it, and you

improve next time, and you start the

process again of warm conversations and

offering a free pilot because of course

ultimately what you're optimizing for

right now is experience, proof, not

money. So, that's day seven. The entire

focus is on deepening the relationship

first. Maintenance or expansion comes

before testimonials. Testimonials come

before referrals. And if it doesn't

work, you learn and you move on without

forcing anything. Now, here's the most

important part. This 7-day cycle is not

a onetime thing. [music] It's a loop

that you're going to have to run through

multiple times. But each loop gives you

more data, more confidence, better

language, clearer positioning, and only

after you've done a few cycles of this

does it make sense to then build lead

lists and apply the same framework to

colder outreach because you actually

have some proof behind your name now. So

then when you do it, it's no longer just

feeling like guessing and feeling random

and overwhelming because you have a

system that works. And that's the exact

path that Christian followed. Start

warm, lead with outcomes, earn trust,

deliver value, and then just repeat. And

if you do this two or three times, you

were no longer a beginner guessing in

the dark. You can see that Christian

actually got his second client basically

just by posting his win in the community

and then someone reached out because

they needed a developer that could work

with clients. So I know that we covered

a lot of information in today's video.

So what I did is I threw all of this

into a practical resource guide that you

can access for completely free in my

free school community. The link for that

is down in the description. Now, if you

did find this video valuable, signing

your first client is only one part of

making money with AI. There's actually

several components involved, and I cover

all of them in detail in this video. So,

if you want to make money with AI in

2026 and click there to check it out.

Otherwise, if you enjoyed the video or

you learned something new, then please

give it a like. It definitely helps me

out a ton. And as always, I appreciate

you guys making it to the end of the

video. I'll see you on the next one.

Thanks, everyone.

Everyone's been asking how to actually

price AI workflows. What's too cheap?

What's too expensive? and how do you

charge enough without losing clients?

So, in this video, I'll break down

exactly how to price your workflows step

by step. And at the end of the video,

I'll give you guys a practical breakdown

of a real example of how I priced one of

my workflows. So, let's get [music] into

it. Before we get into numbers or

frameworks, you need the right mindset

around pricing. Most beginners price

their workflows based on the time it

takes or the amount of effort that they

put in. But businesses don't pay for

your time. They pay for outcomes. When

you build an AI workflow, automation

system, infrastructure, whatever you

want to call it, you're usually doing at

least one of three things for a

business. saving them money, saving them

time, or reducing human error. That's

where the real value is, and that's what

your price needs to be tied to. This is

called valuebased pricing. You're not

charging for the inputs. You're charging

for the return on their investment. And

when you start thinking this way,

everything changes. Instead of asking

yourself, how long will this build take

me? You start asking, "How much time or

money will this save the business every

week? How much more can they generate

because of this system?" Now, I know it

can feel awkward when you're new.

There's always that weird dance of like,

who's going to throw out a number first?

And realistically, a lot of clients

right now genuinely have no idea what

this kind of stuff should cost. But

here's the part that you need to nail.

Whatever number that you say, you should

be able to show them exactly how you got

there. You should almost assume that

after you tell them your price that

they're going to say, "Can you tell me

exactly how you got to that number, you

need to be able to confidently walk them

through that math." Because when you can

explain the ROI, not only do you build

trust, but you come across as a

long-term AI thought partner, which is

what businesses desperately need right

now. And when you explain that clearly

and you anchor that price on real

metrics, suddenly the price doesn't feel

like an expense anymore. It feels like

an investment that will pay for itself

because it will. So once you've got that

mindset locked in, the next step is

learning the actual pricing models that

you can use. So before we dive deeper, I

want to be clear about something. I've

tried almost every pricing model that

you can think of. I've charged a fixed

fee and delivered a JSON file. I've

built hourly. I've sold bundles of

hours. I've done monthly retainers with

no set scope. I've done retainers with

strict scopes. I've literally

experimented with tons of different

models. And the reason I'm telling you

this is because I don't believe that

there's currently an industry standard

way to price AI automation and

implementation services yet. Nobody has

agreed on the right way to price

workflows. Everyone's still trying to

figure it out. But after trying all of

these different models, there are

definitely two that I think work the

best and they work together. So let me

explain what I mean by that. They're

simple, they build trust, and they're

the easiest to scale. So the first model

is valuebased pricing. If I were

starting from scratch today, this is the

model that I would start with.

Valuebased pricing is where you charge

based on the business impact like we

talked about, not the hours that you

spend building. Anchoring your price

around time save, money save, or

efficiency gain. This is the easiest way

to get your foot in the door with a new

client because the math is simple and it

builds trust. What's interesting about

valuebased pricing is that you can build

the exact same system for two different

businesses and you can charge them

completely different prices because

value is not universal. If you tried to

sell me a bottle of water right after

I've run 5 miles in the desert, I would

pay you a lot more than someone who's

been sitting inside air conditioned

office all day. It's the same product,

but it's different value. And that's

kind of the idea behind this value based

pricing. So, you price based on what the

solution is worth to that business. Now,

once you deliver one or two projects,

you build some trust, and you show that

your systems work. This is where you

start moving into longerterm

engagements, which is the next model,

monthly retainers. A monthly retainer is

when a client pays you a predictable

monthly fee in exchange for ongoing

access to your expertise [music] and a

defined level of service. In the

consulting world, these can range

anywhere from 1,500 to 15,000 or more

per month. And it's usually within a 3,

6, or 12 month term. And here's why

retainers matter. Clients get

predictable costs and priority access

[music] and consistent improvement. You

get stable income and a long-term

partnership instead of chasing one-off

builds. And honestly, you'd much rather

work with one $15,000 per month client

than five $3,000 per month clients. Even

though the total revenue is the same,

you'll have less chaos, less stress, and

you get to build a real relationship.

You get to put all of your time and

energy towards that one business. You

get to overd deliver, drive real

results, which is going to increase the

chances that you're able to win more

business in that organization. So, that

will lead to higher CLV or LTV, customer

lifetime value, and potentially more

referrals, which is more business that

is also warm and there's more trust,

[music] and they're easier to close.

Now, retainers do come in different

styles. They could be based on hours,

based on deliverables, or hybrid.

[music] Personally, I would recommend

sort of a milestone-based retainer.

Hours make you look like a freelancer.

Milestones position you as a consultant,

an AI partner. But a big question I get

when I kind of talk about this is, how

do [music] I keep using valuebased

pricing inside a retainer? At this

stage, your goal kind of shifts because

you're not trying to squeeze maximum

value and money out of each individual

[music] project. Your priority becomes

building trust, stacking wins, and

increasing the retainer over time as

your impact [music] scales, almost like

you're trying to work your way into sort

of a chief AI officer type of role.

Plus, as these systems get complex, it's

harder to deliver, test, and refine

everything in a single month. In fact,

that's actually just [music] really

unrealistic, especially if you want the

system to be fully QA before production

and then in production, taking time to

iterate and constantly refine. [music]

So, what you'll probably find is that

you're naturally going to be making more

total revenue on this model anyways. And

it's a lot more predictable. So, the

less time and energy that you spend on

worrying about where your next dollar is

coming from, the more time you spend

making a real impact. And that opens the

door for higher retainers or even

performance bonuses tied to key business

metrics. [music] And don't forget,

you'll also be maintaining the previous

systems, updating things when new models

come out, fixing bugs, making sure that

you're, you know, staying on top of any

updates, and just keeping everything

aligned with the original scope. That

alone justifies ongoing fees. So, the

last thing I'll say is this. We're still

early. Businesses need enablement,

audits, education more than ever. They

don't know what's possible, and they

don't know where AI fits into their

operations [music] even though they know

they need to start using it. So, if

you're already that person who's been

wrapped up in their ecosystem, delivered

real value for them, they'll happily

trust you to guide them through that

process, too. And if you guys want, I

can make a full breakdown video on

audits, enablement, and actually

structuring sort of like educational

offers. Just let me know in the comments

down below. But anyways, after you've

picked the right model, the question

becomes how you actually figure out what

exact number to charge. So, this part

always goes back to your discovery phase

because you can't really give a real

price if you don't understand the

current manual process in its entirety.

That's your job during discovery. Before

you think about pricing anything, you

need to map out the process from start

to finish. So that means you need to

understand things like how often does

the process happen, what triggers it,

who the key stakeholders are, how long

it takes each time, what each hour of

that work is worth in dollars based on

salary, number of employees involved, or

even software costs, and other things of

that nature. And then once you know all

of that, you can start comparing the

manual version to what the automated

version of that system would look like.

But the key here is you just can't

overpromise results. You have to be

realistic about it. So maybe you're

building a system that only automates

half of the process. And make sure

you're factoring in that half, not

automating that full process into your

ROI. But the idea is the second the

workflow goes live, the business

instantly starts getting back time,

money, and focus. And it's your job to

translate that into numbers that the

client can understand. So here's a

simple example. Let's say the process

you're automating is a customer support

process, and it takes the rep one hour

every single day. Let's say 1 hour of

their time is worth $50. Over the course

of a year, that's roughly $12,000 worth

of time that they're spending on that

task. So that means that the workflow

you're building is saving the business

$12,000 annually. And this is where

valuebased pricing kicks in because as a

good rule of thumb, you want the client

to be able to see a 10 times return on

what they invest in that first year. So

if the workflow is going to save them

$12,000, 10% of that would be $1,200.

[music] And that's your starting point

for pricing. You see how easy it was for

me to explain that to you? That's

exactly how you would just want to

explain it to a client. When someone

asks, "How did you come up with that

number?" You walk them through the math

step by step. It's going to build

instant trust. And this doesn't even

include opportunity cost. Because

freeing up an hour of that employees

time every single day doesn't just save

the business money, it's also enabling

that employee to shift their time into

higher value work. Real revenue

generating opportunities. Answering

fewer repetitive customer support

tickets might mean that they can support

new hires, talk to high-v value

customers, or help improve systems,

things that actually push the business

forward. That's why the ROI often

compounds. [music] Maybe month one they

save $1,000, but maybe month two it's

1,500. Month three it could be $2,000.

So over a full year, it could end up

being far more than just that $12,000

that you originally projected. And when

the value grows, so does your pricing

power. Now, once you do a couple of

these projects and you've built some

trust, that's when you can start to talk

about retainers. And this is where the

math does shift a little bit because now

you're not pricing for one workflow.

You're pricing your time, your team, if

you have one, and your ongoing support.

So with a retainer, you want to protect

your margins. Think about what does it

cost for you to operate and for you to

deliver. What is your time worth? What

does it cost if you bring on a

developer? What does it cost if you

maintain the systems that you've already

built? Even if you're not selling hours,

you still need to understand how much

time things are taking because this

helps you think about staffing for

milestones. Here are the [music]

questions I would ask myself. Is this

just me working full-time inside the

client's business? Does this require a

part-time engineer? Does it require a

full-time engineer? Does this also

require an account manager or a project

manager? Once you know those things, you

can start to estimate what it costs you

as a business to run every month. So,

let's say you figure out that servicing

this particular client properly would

cost you $5,000 per month. In the

consulting and agency world, the general

target margin for this type of work is

50 to 70%. 50% is a good baseline to

shoot for. 70% is great and it gives you

room to scale. But just remember that

we're in a service-based business where

the work is very custom and bespoke. So

you have to make sure you're protecting

at least 50% margin. Otherwise, you may

struggle to pay your employees and it

could just get messy. So in this case,

if it cost you $5,000 per month to

deliver, you might want to price the

retainer at $10,000 per month. That

gives you a 50% margin and a lot of

breathing room to bring on help or

expand the scope later. And this is why

I always tell people to start solo or

with one developer because the second

that you start juggling multiple clients

and multiple engineers, your margins can

shrink fast if you're not careful and

doing projections like this. If you've

got a developer on salary, you never

want them sitting idle because you

overestimated [music] workload or

promised unrealistic timelines because

that's how agencies burn cash. If you've

got some developers kind of on the bench

as hourly contractors, it's not as

damaging to the business, but still not

the ideal situation. So when you think

it through and you protect your margins

and you [music] build a repeatable way

of delivering, that's when you get

predictable profit. And predictable

profit is what actually lets you scale,

make more hires, bring on new team

members without tons of stress. Now,

even if your price is perfect and

[music] you have all the ROI

calculations to back it up, how you

present it makes all the difference in

whether a client says yes or no. And

here's the key. You never start with the

price. You want to start with that

transformation before you ever say a

number. You want the client imagining

what the business looks like once that

system is live, what their team's

day-to-day looks like, what problems

disappear, what becomes easier, and once

they're bought into that outcome, the

price starts to make more sense. When

you walk them through the proposed

solution, you want to explain exactly

everything that's actually included in

that total cost. So that usually looks

like setup, hosting, testing and quality

checks, optimization, their involvement

in what you need from them,

documentation, enablement, and training,

and if the conversation goes there,

maintenance. And when the client

understands everything that's included,

it will also be much easier for them to

see your price as an investment instead

of just some random expense. This is

also where visuals help a lot. So simple

screenshots, a small wireframe, or even

a rough diagram of the workflow can make

the process feel real and tangible. If

you've got a working demo or past case

studies, this is the perfect moment to

use them as well. Even in discovery, I

talk about how important it is to be

writing down all the steps while you're

sharing your screen so the client can

see exactly, you know, what you think of

the process and make sure you guys are

aligned. Same thing with a wireframe.

and then you guys are fully aligned

before you ever talk about money.

Because one of the biggest mistakes that

I made early on was having scopes that

were way too vague, way too ambiguous. I

would deliver something and the client

thought that it needed more. And we

ended up going back and forth debating

what done actually meant. When you

present your proposal, be very clear

about what the final outcome actually

looks like. Spell it out, what's

included, what isn't, what counts as

completion. You should have a very

clear, bulleted list of the exact

functionality requirements of the system

in this scope of work. This [music] will

save you frustration. It protects your

time. It sets the relationship off on

the right foot and it prevents scope

creep because naturally as you start

building and the client starts to get

updates and give you feedback, you guys

are both going to realize that there's

different features you'd want to add

into the system. And in that case, you

just have to say, "Hey, I'll add these

to the backlog, all of these feature

requests, and when we do a V2, we can

add them all in. And also, what you're

doing there is you're planting a seed

that there will be future work between

you two. Something else that you need to

make clear is the QA process, the

quality [music] assurance process. Even

the best workflows need a real testing

period before they go into full

production. And even then, you want to

consider constantly monitoring them and

evaluating them. That means you first

have internal QA, internal testing. Then

you have the client do testing and

feedback and you fix bugs and you add

small adjustments and then you do

another round of internal QA, client QA.

Finally, you're able to evaluate it with

live data and then consider pushing it

into full production. And you need to

make sure that they understand their

role in the process because they're

going to have to give you access to

tools, provide test data, answer

questions quickly, give you feedback,

and if they're slow and unresponsive,

then everything kind of slows down and

that is not on you. So once again,

setting these expectations up front

makes the project smoother for both

sides. Now, of course, not every client

will instantly agree. So you do need to

know how to handle objections without

lowering your value. If they push back,

adjust the scope, not the price. Reduce

complexity, remove a feature, break it

into phases, but [music] don't discount

the value that it's actually providing.

And as you talk to more clients who

start to notice these patterns in their

objections, and once you see those

patterns, you can start to address those

concerns before the client even ever

brings them up. This is how you remove

those hidden costs and it builds a lot

more trust. When someone is budget

sensitive, bring the conversation back

to the long-term value instead of the

short-term expense. You can remind them

that the goal is to save time, money

every single month, not just to have

something built. It's [music] also super

important to understand when to walk

away. Just because someone is willing to

pay you $10,000 upfront, that does not

mean you want them as a client. If they

undervalue your work, question every

step, or they show early signs of being

a difficult partner, walking away is

often the best decision. Protects your

energy and your reputation. A lot of

times, it just might be a feeling that

you get in your gut. One of the most

common questions I get is about

intellectual property though, so I

thought I'd address that here for you

guys real quick. Clients want to know if

they will own what you build. Now, the

simple answer is yes. It's just the best

way to handle it. All IP that we build

for them is [music] theirs. I usually

handle this by saying, "Yeah, we build

on open infrastructure. We use internal

components or templates to speed up

development. But the real IP in the

system is the prompts, your data, your

workflows, and how everything is

combined in this ecosystem." So that's

[music] very specific to your business

and provides no value to anyone else.

You're not losing anything by giving

them ownership. Just make sure you're

protecting your own reusable components,

though. So, that's only one example of

an objection. In the free resource guide

that will come with this video, I'll add

like six more common objections and

exactly how you can handle them. You can

download it for free inside my school

community. The link for that will be

down in the description. So, once you've

closed a few clients, the next step is

turning those one-time projects into

consistent recurring income. Even if

you're not on a full monthly retainer,

you can still introduce simple recurring

services that can benefit both sides.

These are small add-ons that create

stability for you [music] and peace of

mind for the client. and they're easy

for clients to say yes to because

they're tied directly to maintaining the

system that you already built. So, here

are a few examples. The first one you

could do is a maintenance fee. This is

one of the simplest add-ons. You can

charge a small monthly fee to make sure

that their workflow stays healthy if an

API changes, if a model updates, if

something breaks, or if the client needs

minor feature enhancements. You're there

to keep everything running smoothly.

It's a light retainer that covers

reliability and support. Now, this could

be a flat monthly fee, something like

200 to 1,500 bucks per month per system.

Second option is kind of optimization

and monitoring. This is another option

that is ongoing optimization. You can

check the systems weekly or monthly,

review logs, look at outputs, and

tighten things up so the workflow keeps

improving over time. This is really good

for AI heavy systems because the prompt

tuning, the new models, the quality

checks, and the retrieval steps often

get better the more that you iterate and

the more feedback you get from the real

world. And then the third one is

expansion projects. This one's big. Like

we talked about earlier, whenever you

sell a valuebased project, you and the

client almost always uncover a backlog

of improvements, new ideas, or version

two upgrades. and that's completely

normal. It's also a perfect opportunity

to turn a one-off project into a

longerterm partnership. Now, the beauty

of these different retainers is that you

could sell just one of them or all three

of them as a package. You can think

about pricing all of these different

retainers as a monthly fee, maybe

somewhere from 200 to upwards of 1,500

per month, but you could also do it as

an hourly maintenance package where you

would give them maybe 5 to 20 hours per

month and assign a dollar amount to

those hours. Or the last way, which is

probably the best way to do it, would be

a percentage of the original project

cost, anywhere from 10 to 25% of the

price that they paid. So, recurring

revenue makes your income more

predictable. It makes your

month-to-month more stable. But the real

purpose of these add-ons is relationship

building. Because every time that you

handle maintenance, optimize something,

or help them launch a V2 or a V3, you're

reinforcing [music] that you understand

their business, their workflows, their

processes, and their goals better than

anyone else does. And that's how you

become the partner that they trust, the

person that they can call when something

important needs to get built. And the

deeper that they become integrated with

you, the harder it is for them to switch

vendors. You're embedded. You're the one

who knows how everything works under the

hood. And that's leverage. The more

value you provide, the more expansion

work you will likely unlock. And that's

how you build a business that grows

consistently instead of constantly

trying to find new clients. So to make

all of this easier to repeat, it helps

to have a simple internal framework that

you can follow every single time that

you price a workflow. That's why I came

up with the price framework. [music]

It's a five-step process that takes all

of the guesswork out of pricing and

makes sure that you can stay strategic,

consistent, and grounded in value. So

the P is for prepare. We started off

this video talking about the mindset. So

before you even think about numbers,

make sure you're grounding everything in

value based pricing. Just remember,

you're not charging for hours. You're

charging for outcomes, and you're

building systems that [music] save time,

money, and reduce human error. The R is

for research. So, this is your discovery

phase. You want to fully map out the

manual workflow from start to finish.

How does it happen? What triggers it?

Who does it? How long does it take? What

tools are involved? What does the time

cost the business? So many things that

you need to figure out. And you have to

use this to actually be able to price it

properly, which leads directly into the

eye, which is for identify. Identify the

ROI. This is where you turn your

research into actual numbers. What are

the monthly savings, annual savings, the

opportunity cost, the efficiency gains,

and remember the 10 times investment

kind of golden rule. They should roughly

see 10 times the return on whatever they

pay you within the first year. The C is

for communicate. Now that you have that

price, you still have to present it in a

way that makes sense. You want to paint

the picture of what the business will

look like once the system is live.

Explain what's included. Explain how QA

works. Explain [music] what you need

from them. If you can't communicate

clearly, you'll probably lose them long

before you even get to the price

conversation. [music] And then the E is

for expand. Once the project is

complete, your job still is not over.

You want to look for opportunities to

continue building on top of that

relationship. That could be maintenance,

optimization, monitoring, additional

workflows, V2 upgrades, retainers, or

performance bonuses. Your goal isn't

just one sale. Your goal is to become

their long-term partner. So, this

framework gives you a repeatable,

reliable way to price any AI workflow,

whether it's your first project or your

hundth. So, to wrap this up, I wanted to

show you guys a practical example of how

this framework works in real life

because once you see the numbers laid

out, pricing becomes a lot less scary

and a lot more logical. So, we worked

with a client who wanted help with their

inbound sales process. They were getting

about 20 leads every single week from

their form on their website. And every

one of those leads took about an hour of

an employees time to reach out, qualify

them, nurture them, and ultimately have

them book in a call with the sales team.

These employees who set those meetings

were valued at about $40 per hour. So,

this meant that this one process was

costing the business $800 per week,

which is $3,200 per month. And when you

zoom out and you annualize it, it ends

up being about $38,000 per year. So,

let's walk through that example with the

price framework. So P prepare. Right

away I grounded myself in value based

pricing. My job here was not to think

about how long the workflow would take

me to build. It was to think about how

much value it will return to the

business. The R is for research. Then

came the discovery phase. We mapped out

the entire manual process. When leads

came in, who handled them, exactly how

long it took, what tools they were

using, and where the bottlenecks were.

That's how we arrived at the $38,400

per year in labor costs opportunity. I

identified the ROI. Once we had these

numbers, the investment became obvious.

I knew automating that process was going

to save them about $38,000 in a year

alone, not even counting the opportunity

cost. So, I priced the product at 15% of

those annualized savings, and that came

out to $5,500. Because the ROI was so

clear, it made complete sense to them,

and they could see exactly how the

system would pay for itself. See,

communicate. Before I ever said the

price, I walked them through the

solution, how the sales agents would

work, what steps it would automate, what

testing would look like, what I would

need to know from them, and how it would

improve both speed to lead and lead

quality. I also showed them how we would

track success. By the time I anchored

the price, they already believed in this

outcome and they were bought in. [music]

And finally, the E expand. Once we moved

into QA and prepared to push the

workflow into production, that's when we

started to talk about ongoing support.

We agreed on a simple maintenance and

optimization plan at $550 per month,

which is about 10% of the original

project's fee. This covered bug fixes,

keeping everything aligned with the

scope, making adjustments as models

updated, and running monthly health

reports. Now, this is where we actually

did mess up. I should have been proving

to the business how valuable the system

really is once it was pushed into

production and show them how it was

actually growing the business. So in

hindsight, I should have been tracking

things like how fast leads were being

contacted, which was basically [music]

instant now, how many leads per week

were coming in, how much total time was

being saved and how the sales team felt

using the system. And if we were

actually tracking all of these metrics

kind of, you know, month after month and

we're able to show them that, it would

be very clear how the system is

explicitly growing the business. And

this would have given the client more

visibility into the actual impact and a

natural entry point for us to make

version two improvements and the

potential of getting them on a retainer.

So, I know that we covered a lot of

stuff today and I want to make sure that

it all sticks. So, I've thrown all of

this into a full resource guide that you

can get for free by joining my free

school community. The link for that will

be down in the description. And if you

want to dive a little bit deeper, I've

got a full course on all of this kind of

stuff. I talk about everything that I've

been talking about on YouTube, but in

much more depth. So, if that interests

you, then definitely check out my plus

community. The link for that is also

down in the description. Anyways, that's

going to do it for today. If you guys

enjoyed, you learned something new,

please give it a like. It definitely

helps me out a ton. And as always, I

appreciate you guys making it to the end

of the video. I'll see you on the next

one. Thanks everyone.

Okay, so before we get into this next

one, which is talking about delivering

and handing over workflows or

automations, I just wanted to clear

something up because what you'll notice

is in the video I do make a few specific

references to nen and obviously this

course is about cloud code. But the

reason why I wanted to still include

that is because the foundational

concepts are still the exact same. The

conversation just moves from okay,

instead of an NN JSON workflow, it's now

just like a Python script or a

TypeScript or whatever coding language

you use. The key confusion with NN was

like, okay, who owns the account and

where is the account hosted? Now the

question just becomes whose GitHub or is

this in? Whose trigger.dev or you know

similar hosting platform does this

actually live in? Whose domain or cloud

project is the automation running under?

You still have the exact same three

layers about account ownership, about

infrastructure ownership, about access

control. The only thing you want to be

careful about is if there's a specific

provider that has some sort of licensing

agreement or terms of service that you

have to make sure you're not violating.

But essentially, it's the same

conversation being upfront with your

client and saying, "Hey, where do you

guys feel comfortable with this living?"

Okay, I need to either have you send me

over the API keys in an encrypted way or

you need to sign in over here and put in

your environment variables, put in the

API keys so that this automation can

run. Whether that's on a trigger.dev

account that I own and I charge you for,

or whether that's one that you spin up

and then I just basically put my

automations in there. Just remember, at

its core, an automation is code. So, you

just have to figure out where does that

code live and what does that code need

in order to run every day. So, like I

said, as you're watching this next

section, just keep that in mind. So, you

guys are always asking me, Nate, how do

I host workflows? What does the handover

process look like? Should I host a

workflow to the client? What about

security? These types of questions come

up all the time. And since there's

literally no good video covering all of

it, I figured I'd make one. So, in this

video, I'm going to walk you guys

through the entire process of fulfilling

an AI workflow or agent after a client

pays you step by step. And at the end,

I'll show you a real example from one of

the first AI workflows that I ever sold.

Let's get into it. So before [music] you

build anything, the first question that

you have to answer is simple. Who is

going to host the workflow? I get this

question constantly. And since most of

you guys are using NDN, I'm going to

frame this answer around how NN actually

works because its license is actually

kind of what decides what you can and

cannot do. I've also worked with tons of

different clients and I've delivered

workflows to them in tons of different

ways. So I basically just charge for the

JSON file and then I would give that to

them as well as a Loom setup guide of

how it works. I've had them invite me to

their own end account and I would just

develop right there in their own

environment. I've developed the workflow

in my own environment and then they

would give me their login credentials

and I would log in and port everything

and then I would just log out and I've

also helped people spin up their own

instance of NadN and then they would

invite me once they have the account

[music] as a team member. So I say all

that to say that there's a lot of

different ways to do it. So let me tell

you about the main options and what I

recommend. So the key rule that you need

to know is that you can only use Nitn

for your own business internally unless

you have a paid commercial or enterprise

license if you're hosting it. You are

allowed to sell services around nitn but

you are not allowed to turn nitn into

your own product. So everything about

hosting comes down to one thing. Is this

nen instance being used by one business

internally or are you exposing it as a

platform to other people? So now that

we've gone over that rule, we have three

options for hosting workflows and

honestly I would pretty much always go

with the first option and that's what

I'm recommending to you all, but I'll

still touch on the other two because

it's still important to understand the

difference. All right, so option number

one is where the client hosts NAD. This

is the safest and cleanest model for

almost everyone. This means that each

client that you're working with would

have their own nitin instance and you

simply work inside of it. So what this

means is that the client either buys

their own anoden cloud and invites you

as a user or they sign up on a

self-hosted instance or locally hosted

instance and then they give you access

to it. Now I know that as a service

provider you want to make their

experience as frictionless as possible.

So what you can do is you can help them

set it up. You can help them configure

their server or even provision an

account for them, but then they have to

own it and they have to pay for it

because you can't mark up the hosting or

essentially charge for access to NIDAN.

This [music] helps you stay compliant

because Naden is being used for that

company's internal business processes.

You are just providing consulting and

workflow development which is completely

allowed and you are not giving multiple

clients access to the same instance.

This is basically the Zapier model where

every client has their own seat and

you're the builder. So if you're doing

client work, this is what I recommend

pretty much all the time. Now option two

is you host NM but only for your own

agency. So in this setup, you run nitn

on your own server, but nobody else sees

it except for your business. And this is

for your own internal automations like

lead routing, content workflows,

internal AI agents, or anything else

where the client never touches NADN

directly or ever needs to. Now, you can

also deliver a service using Eniden

running on your own infrastructure. As

long as clients don't log in, don't

connect their own API keys, things like

that. This is compliance because NIDAN

is only powering your own operations.

You're not exposing it as a hosted

platform and you're not giving clients

access to it. So just think of it as

your own internal engine. And an example

of this could be if you were sending a

client something like an automated

report or research and as a service to

them that's what you're basically

delivering even if your own internal

automation is powering that on your own

hosted NN that's fine because they are

just paying for that deliverable. Then

option three is when you host N&N as the

product and this is where you would need

a commercial or enterprise type of

license. This is the line that you

cannot cross on the free or the

sustainable use license. So essentially

you cannot build a SAS product software

as a service product where NN is the

value. Even if the client never sees the

NN UI if your offer is basically give me

your credentials and I'll run your

automations on my end server. That is

not allowed without a commercial

agreement. And this model only really

makes sense if you're building out a SAS

or you're selling automation as a

subscription where ended is clearly the

engine. If that is the case you

definitely want to talk to end sales and

get a commercial or enterprise license.

And I will say those things are not

cheap. So the short version is simple.

If you're building workflows for clients

let them host it. If you're running

automations for your own company, host

it yourself. And if you want to build a

SAS or platform, you need a commercial

license. And once you've decided where

the automation will actually live, then

you can move into planning out the

build, structuring the data, and

preparing for the handover. So next,

let's look at security and data

protection. Once you've built the

workflow, your job is to make sure the

data moving through it stays secure.

That means no leaking sensitive

information, no exposing personal data,

and no breaking privacy laws like GDPR.

So let's go over how Aniden handles

security and how you can explain this

clearly to your clients. And in a few

minutes, I'll talk more specifically

about API key management and billing

since that also deserves its own

section. The first thing to understand

is how Naden protects sensitive fields

inside of your automations. Credentials

inside Naden are encrypted at rest and

they're decrypted in memory at the

moment the workflow runs. So these nodes

with your credentials in there simply

reference credentials by name. And if a

teammate or client doesn't have

permission to that workspace that has

those credentials, they won't be able to

see the raw values, the API keys, the

passwords, whatever you want to call

them. This is why handing off a workflow

is safe when it's done correctly because

you're not exposing sensitive fields

inside nodes and you're not storing

anything in plain text. The platform is

built to keep secrets locked away so

only the automation engine can access

them when it needs to. Another big part

of security is web hook hardening. So a

web hook is basically like a public door

into a workflow which means you need to

treat it with the same seriousness as

you would any inbound request to an

application. So maybe this means using

HTTPS so that data is encrypted in

transit or signing secrets or

verification tokens for services like

Stripe, GitHub or any provider that

supports signature validation. What you

can do is have EndN verify that

signature before it actually trusts the

payload and lets it into the workflow

and never put sensitive data inside the

URL of a web hook. And if you really

want to get advanced and a little more

technical here, if the use case called

for it, you could implement things like

rate limits or additional authentication

checks to prevent spam, brute forcing or

automated abuse. So the way I would

explain this to clients is simple. Every

external trigger hitting your automation

must be authenticated so that only

approved systems can talk to this

workflow, which means random people

cannot guess the URL and start hitting

your CRM or your internal systems for

data. And while we're on this topic,

it's also worth thinking about prompting

in some guard rails and building a

system so that people can't jailbreak or

prompt inject your AI agents. Now,

another big responsibility is handling

CRM, payment, or other personal data

because this information is often

regulated under GDPR and similar laws.

Anything that could identify a person is

protected. So, this is not legal advice.

However, there are a few basic best

practices to follow, but you should

always be consulting with professionals

based on your industry and your laws

that govern you and your clients. But

you could do stuff like using data

minimization, which means only bringing

in the fields that you actually need.

You could limit who can see the workflow

runs, so only the right people have

access to the logs and the payloads. You

should also understand that a client

must have a legal basis for collecting

and processing the data that they're

passing into the workflow. And if you're

processing data on the client's behalf,

you're usually acting as a data

processor, which means you may need a

data processing agreement in place. You

also need to make sure that your

automations don't make it impossible for

the client to honor requests like data

deletion, data corrections, or access

requests. Basically, what that means is

you should know exactly where the data

flows so that it can be removed or

updated if needed. And Naden helps with

this because you can prune executions,

trim logs, and limit the amount of data

that the system stores over time. And

one of the biggest advantages of NADN is

that it's source available, which is

essentially better known as open source,

which means that it can be fully

self-hosted, which gives the client the

option to keep all of their workflow

data in their own environment. So you

can run noden on their infrastructure,

connect it to only tools that they

approve and trust and even use local or

self-hosted AI models instead of sending

data to OpenAI or other closed source

proprietary models. This gives true data

sovereignty. The client chooses where

the server lives, how it's secured, and

who has access. So for privacy sensitive

clients, this is a huge selling point.

Instead of pushing sensitive data

through random cloud services, you can

run the entire automation engine inside

their own locked room, whether that's on

prem or inside a private VPS. And that's

the foundation of security and data

privacy. Your job is to build workflows

that move data safely, keep sensitive

information protected, and give clients

confidence that nothing is leaking. And

now that you understand the security

side, the next section I'm going to walk

you guys through is about API key

management and billing because that's

another area where I get a ton of

questions. So, the main ones I get are

who owns the API keys and who pays for

the usage. And the cleanest answer I can

give you is that the client should

always pay for their own API keys and

usage. This keeps everything

transparent, predictable, and it avoids

a lot of headaches later. So the ideal

setup is having the client sign up for

the tool themselves. Enter their billing

information, generate the API key, and

paste it directly into Ended. When you

do it this way, the key never gets sent

over the internet to you, and the client

keeps full control over their account.

They can see the usage, they can see the

charges, they can turn it off if they

want, and nothing about the automation

is hidden from them. It's just a much

cleaner working relationship. Now, the

best way to do this, because like I

said, you want to remove as much

friction as possible, is to send them a

Loom video walking them through exactly

where to click and how to create that

key and where to paste it into N. Just

keep it dead simple for them. You could

even walk them through it on a Zoom call

if they prefer. Now, could you set up

the API accounts on your side and then

just build them later? Yes, you could.

There's nothing about that is

non-compliance, but it could create all

kinds of problems because they don't see

the usage. They don't understand where

their money is going. And if you're

marking up usage or you're charging a

fixed rate, it can get confusing fast.

As the automation scales or if something

breaks or spikes, even if it does feel

easier right in the moment because the

client doesn't actually have to go do

anything, it definitely in the long run

can create more questions than answers.

So, letting them own it and pay for it

keeps everything clean. Now, if a client

is intimidated by that process and wants

you to handle the key directly, you

still want to make sure you're

transferring it securely. So, just send

them over Slack, ClickUp, text, or

email. Have them drop it into some sort

of secure vault like a one password or

any encrypted secret sharing tool where

they can generate a onetime link. Then,

you can copy that key into NADN yourself

and that link can expire or something

like that so that no one else could ever

access that vault. As a small bonus

feature, you could even think about

offering them a dashboard that shows all

their API keys and all the billing in

one spot. That gives them visibility and

it gives you credibility because you're

helping them manage their system like a

real piece of infrastructure. So the

simple rule is clients own their API

keys, clients pay for their usage and

you make the process painless for them.

This keeps everything clear, secure, and

scalable as the automation stack grows

and as your professional relationship

matures. Now once all that's been

decided and you're actually starting to

think about handing over the project,

you have to make sure that it's been

fully tested in the right way before you

actually send it over. If you're not

careful, the workflow may have bugs that

you didn't spot before and this can hurt

your reputation and relationship with

the client. So, the first step is

planning your test data with the client.

You don't want to test with madeup

examples that have nothing to do with

their business. So, early on, ask them

for a small sample set that looks like

real usage. I typically do this before

we sign the contract so they know what

is expected of them because if they

delay getting you all that sample data,

then it's going to delay your process as

well. So, that could be emails, support

tickets, transcripts, CRM records,

whatever actually fits the workflow when

it's in production. And of course, if

needed, they can anonymize it. Then, you

can agree on what success looks like and

what is a good output and what must

never happen. things like wrong tags,

broken links, leaking info, or sending

the wrong person the wrong message. So,

you can explain it very simply. Before

we go live, we're going to run your real

examples through the system so that you

can see exactly how it behaves. And then

inside your own testing, you want to

think less like a developer clicking in

every node and looking at the

configuration and think more like an

engineer who's planning for failure. So,

with automations, especially when they

have AI, you have to accept that you

don't know what you don't know. And once

the system goes into production, real

users and real data will always reveal

edge cases that you didn't think about.

So during testing, you should

intentionally look for worst case

scenarios and ask yourself what happens

if this, what happens if that, bad data,

no data, duplicate data, or even

something completely unexpected. Instead

of assuming the workflow will run

smoothly forever, you want to build in

guardrails. Maybe the workflow can time

out gracefully so nothing happens. Maybe

you set up an error workflow that alerts

the team. Maybe you log all failures

into a Google sheet so you can track

patterns over time. The idea is not to

eliminate every possible issue because

you can't, but to make sure that when

something does break, it breaks safely

and quietly and in a way that gives you

enough information to go fix it fast. So

once that works, you step back and you

treat the whole workflow like a black

box. You feed in a lot of examples, not

just one or two, ideally dozens or even

hundreds of sample inputs if you can get

them. And then for each one, you log

what came in, what happened in the

middle, and what the final output was.

Then you compare those outputs to the

success [music] criteria that you agreed

on with the client. You flag the

failures, the weird edge cases, and

borderline results that you want to talk

about with them. And this is your

internal QA or quality assurance pass.

The goal is to catch as much as possible

before the client ever tries it. And I

would do internal QA for at least a few

days before having them get in there and

provide any feedback. Now AI adds

another layer on top of that because

you're not just checking that the AI

node runs. You're checking the quality

of what it says. So for beginners, focus

on a few simple checks like relevance

and correctness. Does the answer

actually respond to the request with

accurate information? Another thing is

tone and safety. It shouldn't be toxic,

off-brand, or leaking hidden system

prompts and private info. And then

you've got the element of consistency.

So, if you send in the same 10 inputs,

are you getting roughly the same 10

answers every time? And behind the

scenes, you can run simple AB tests and

evaluations where you try different

prompts and different models on the same

data set and track which ones give you

the best results. And to the client, you

can phrase that like, "We tested several

prompts and models on your real examples

and kept the one that hit the highest

quality and the most consistency. Here's

the evaluation data we ran." And you

could even use Eniden's built-in

evaluation feature. Of course, you have

to be able to actually show all that.

So, that's where logging comes in. And

logging is what makes all of this not

feel like magic because I like to have

my workflow store execution history in a

Google sheet where it tracks all the

inputs, all the outputs, the tool calls,

the errors and tokens so that you can

actually look through this log and you

can identify patterns, common failure

types, recurring bad inputs or weak

spots in your prompt or model choice.

That same log becomes your evidence when

you talk to the client and you can show

them what you tested and why you made

certain decisions or improvements. And

after you're happy internally with the

system, you can move to the client-f

facing QA where you give them a clear

way to test the system. That might be a

chat box or a form or a simple UI. Just

make it simple. You don't want them to

actually have to get into Nen and look

at all of that mess. Then you ask them

to tell you what they think about the

system, about the outputs, the tone, the

formatting, anything like that. And a

lot of times at this point, if you did

everything right, you will just be doing

little prompt tuning and model tuning

tweaks. And then to wrap up, you can

record a short update video, show one or

two full runs from the input to workflow

to output, point to the logs, and

explain how the system handled those

real examples. And that is the kind of

QA or quality assurance that builds

trust and makes clients want to work

with you again. Now, once you've tested

the workflow successfully, it's time to

start the handover process. This is the

delivery phase and it looks a little

different depending on your current

situation. So, the first thing that

could affect handover is whether or not

you built the workflow directly in their

environment because if you did, the

handover is a lot easier because

everything's already set up and their

credentials and everything like that.

But if you didn't, then you'll have a

bigger transfer process where you

actually help them move credentials and

you have to recreate some of those

connections. The second thing that can

affect your handover is whether or not

this is the end of the project or if

you've already scoped out more work or

some sort of ongoing maintenance

retainer. If you're sticking around, you

might keep some testing infrastructure

in place, but if you're not, then your

handover needs to be more final and

complete. There are a few key steps you

want to follow either way. First, you

want to duplicate the workflow. So, keep

one version somewhere as a backup or a

testing version and then push the clean

one into production. This is exactly how

software teams work. You kind of have a

test environment where you experiment

and iterate and then you have a

production environment where only a

stable version lives. So anytime that

you need to make changes or updates, you

do that on the test version first.

Confirm that everything still works and

then you can move that version into

production. And that same idea can apply

to when Naden itself releases updates or

when the tools or integrations change.

You never want to just update your

production environment blindly. You want

to update the test setup first, load the

workflow, make sure all the

functionality is still intact. And then

once you know it still behaves as it

should, then you can update the version

that the client would actually rely on.

This avoids outages, broken automations,

and a lot of unnecessary stress. On top

of that, you always want to back up your

workflows. So you can store the exported

JSON on GitHub, Google Drive, or even a

simple Google sheet. So you always have

previous versions that you can revert to

if needed. And if you want to go a step

further, you can build an automated

backup process using an itself so that

it periodically exports and saves the

workflows somewhere else. The next thing

you want to do is about workflow

hygiene. So you want to make sure that

it's clean and easy to understand. Use

clear naming in each step, label each

step, have sticky notes around the

workflow explaining what it's doing and

why you built it that way. The goal is

that anyone from their team or your team

later on could open up that workflow or

have a PDF of that workflow and see and

understand the logic right away. You

also want to double check that there are

no sensitive keys or tokens anywhere in

the workflow before you hand it over

because you want a clean handoff where

the client knows exactly where their API

keys go and how to set them up on their

own account. So in this set of

deliverables, it could also have a Loom

walkthrough where it's a quick 1 or 2

minute video where you show how the

system works, how to configure it, and

what to do if certain elements need

updating because there's never one exact

right solution for a process as far as

like how to automate it. And everyone's

brains work a little differently. So if

you can explain to them what you were

thinking when you built it, it's going

to be really helpful. And whether this

is the only project you're doing for

them or if you're staying on retainer,

good documentation is always valuable

because like I said, if someone on their

team later takes it over or if you bring

in a developer later to help maintain

the account, everything is super clear

and no one has to guess what was built

or why. And it really protects both

sides because it helps the client feel

supported and confident. And it helps

you avoid being the bottleneck whenever

something needs to change. And this is

how you deliver workflows professionally

and set yourself up for a long-term

relationship instead of one-off

projects. Now, this is the part that

people never really discuss online, and

that's the legal and financial side of

things. After handing over the workflow,

there are a few things you want to make

sure are agreed on in advance. And the

first one is billing. You want to be

crystal clear on this. First, you close

out the current project and get paid for

what you just built. Then, you decide if

there will be an ongoing paid

relationship to keep everything healthy

over time through a maintenance

retainer. Before anything else, you want

to revisit the scope of work that both

of you guys agreed on at the start. Your

contract or scope of work should already

say what finished means, which workflows

you promised to build, which systems

they would connect to, what success

looks like, essentially what the

definition of done is. Because at

handover, you want to walk through each

item and confirm that everything works

the way that you agreed. And once the

client confirms that the project is

complete, you send the final invoice.

You can frame this as simple as the

project ends when the agreed workflows

are live, tested, documented, and

accepted. And then the project invoice

is due. The next piece is deciding if

you want to offer a maintenance

retainer. A retainer is a separate

ongoing agreement where the client pays

you to keep the system up and running.

This usually covers things like bug

fixes, small tweaks, updates, dependency

changes, monitoring, and basic security

checks. It does not cover new features,

new workflows, or major scope changes.

Those should be a separate project. You

can also set basic service levels so

clients know what to expect. For

example, a critical outage might get a

response within a few hours. Minor

requests might be handled within a few

days. These don't have to be

complicated, but the expectations there

should be clear. Now, you also want to

get clarity on ownership and IP. Many

consulting agreements say that the

client owns the work product once paid,

but you should still protect yourself so

that you can keep the right to reuse

generic patterns or components that are

not specific to their business, such as,

like I said, reusable tools or

subworkflows or basic templates. It also

helps to define the exit process. So, if

the client ever wants to move away from

your services, you should outline what

you will hand over. This could include

exported workflows, documentation, and

handover call along with what is

included and what is billable. So, a

simple explanation of this is once the

product is paid for, the client has the

right to use and run these workflows in

their business. If they later want to

move providers, you will help handle

everything off in a structured way. For

beginners, the main thing is simple.

Stop doing all of this informally. Put

scope, definition of done, payment,

maintenance, service levels, bugs versus

changes, ownership, and exit terms into

a clear written agreement. When both

sides know what they are buying and what

happens after going live, projects run

smoother and you avoid miscommunication.

So now that you know what to do in

theory, let's take a look at a real life

example of a workflow that I sold and

the process I went through when handing

it over. So this one was a personal

assistant workflow and one of the first

ones that I ever delivered and the

client had never actually heard of N& he

just watched my YouTube video of the

ultimate assistant and then reached out

and said that he wanted something like

that. So after discovery and after

signing the contract, we got on a

kickoff call and on that call I had all

of these things that I needed from him

which were listed out in sort of like

our client expectations portion of the

contract. So, I walked him through

exactly what we needed to get and I

helped him go get those API keys, sign

up for an end account, things like that.

And then I showed him how to invite me

to that ended instance. Right there on

the call, we connected his CRM, his

calendar, his email, and the data

sources that he wanted this assistant to

be able to use. From there, I was able

to just plug in a few of my own

credentials for testing purposes [music]

and then I could just hit the ground

running. And the best part about this

was at the end, a handover was almost

instant because all I had to do was swap

out a few of his credentials for mine

and then he [music] could just start

using it right away and giving me

feedback. Now, with something like a

personal assistant that is super

autonomous, QA can be intense because

it's super conversational and there's

[music] lots of different tools that it

could call. It's also client facing. It

has memory. It has tone. It has lots of

things that you need to actually make

sure that the client is happy with. So,

there was a lot of back and forth. There

was a lot of tweaks, refinements, and

specifically with the system prompt, and

[music] that's completely normal. But

throughout this process, he began asking

for bigger features, new integrations.

And at that point, I had to protect the

scope because that's super important to

make sure that we're not adding in all

the stuff that you're not getting paid

for. So I told him which of those

requests would fit inside version one

and which ones would need to be added to

the backlog for a future phase. Then

after version one was complete and

accepted, we would scope out a new

project around those extra features. So

that alone saved me from doing a ton of

unpaid work. And the final lesson here

ties back to API keys. Early on, I used

to try to make things easy for clients

by running everything under my own

billing and just sending them an invoice

at the end of the month. Now it sounds

nice in theory, but in reality, it gets

messy fast. Like I mentioned earlier,

clients want predictable costs and token

usage is impossible to estimate

perfectly. You also could deal with late

invoices or confusion about what they're

actually paying for. And it all just

comes back to the same rule. It's so

much cleaner and simpler and way more

scalable if they own those accounts and

their keys from the start. It makes the

handover easier. It makes maintenance

easier. And it keeps you out of the

billing babysitter role. So hopefully

seeing a real example gives you a better

sense of how all the pieces come

together in a live client project. This

is how you build, host, test, handover,

and maintain AI workflows without

creating headaches for you or the

client. So that's the full process.

First, you decide where the workflow is

going to live. I always recommend that

clients self-host everything whether

that's ended in cloud, a VPS or

something local and you just help them

configure it. Before you deliver

anything, you make sure security and

data privacy are handled the right way.

Then you figure out who owns what with

API keys and how those keys get into the

system without creating a mess. After

that, you run your testing and QA so you

know that the workflow is reliable,

safe, and producing the right outputs.

Then you move into the actual handover,

which is how you deliver the system, set

expectations, and give them

documentation. And finally, you close

out the project on the legal and billing

side and decide if there will be ongoing

maintenance after go live. That's the

full life cycle of building and

delivering AI workflows the right way.

So, I know that we covered a lot of

information in this video. So, what I've

done is I've thrown all of this into a

full resource guide that you guys can

access for completely free. All you have

to do is join my free school community.

The link for that is down in the

description. If you enjoyed this one and

you want to dive even deeper, then

definitely check out my plus community.

We've got over 3,000 members in there

who are building businesses with NN

every single day. So, it's a great

environment to surround yourself with

like-minded people. So, that's going to

do it. If you learned something new,

please give it a like and subscribe. It

definitely helps me out a ton. And let

me know what else you guys want to see

in the comments. As always, I appreciate

you guys making it to the end of the

video. I'll see you in the next one.

Thanks, everyone.

If you guys are watching this, it means

you made it to the end of the course.

And I just want to say a huge thank you,

but also congratulations. You just sat

through so many hours of me talking. I'm

sure you guys are sick of my voice. But

like I said, I just wanted to say thank

you. I put a lot of time and energy into

this course, so I really hope that it

was beneficial for you. So, if it was, I

would really enjoy if you could leave a

like, drop subscribe. That would mean a

lot to me. And if you want to continue

to support me, then definitely check out

other resources. One of my biggest

passions right now is AI Automation

Society, as you can see by this

sweatshirt that I've been wearing pretty

much this entire course. You can check

it out. The link for that is down in the

description. It is my free community

called AI Automation Society. And we've

got hundreds of thousands of members.

And my goal is just to make it a

resource hub for people that want to

learn AI, but also just like a really

cool place for people to meet each

other. and we're going to be doing some

virtual events every quarter. We're

going to be doing inerson events. So,

that would be a great way to support me

would be by becoming a member of AI

Automation Society. And building on top

of AI Automation Society, we also have a

plus group. We're also going to have

higher ticket tokate coaching coming

out. So much more stuff is going to be

coming in the AI Automation Society

ecosystem, which I'm really pumped

about. But that's my pitch. I appreciate

you guys as always making it to the end

of the video, and I'll see you on the

next one. Thanks so much everyone.