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.