TLDR
This 6-hour course by Nate Herk teaches non-coders how to become AI-native using Claude Code, covering everything from installation and mindset to building skills, sub-agents, agent teams, and deploying automations. The course emphasizes practical skills like context engineering, iteration, and token management, with step-by-step examples showing how to build a personal AI operating system without writing code.
Key points
- Claude Code is an AI harness that allows non-coders to build automations and agents using natural language, accessing local files and online tools.
- The course outlines six essential AI skills: becoming the AI person, taste and judgment, context engineering, iteration speed, building your own Jarvis, and unemployment insurance.
- Skills are markdown files that package processes and can be invoked by natural language or slash commands, with progressive disclosure to save tokens.
- Sub-agents run in separate context windows, enabling parallel work and cost savings by using cheaper models like Haiku for research tasks.
- Agent teams allow multiple specialized agents to collaborate on a shared task list, useful for debate and multi-perspective analysis.
- Deploying automations can be done via Claude Code routines (cloud-based scheduled tasks) or Modal (Python scripts for deterministic workflows).
- Token management is critical: use fresh sessions, batch prompts, disconnect unused MCPs, compact at 60% capacity, and leverage prompt caching to reduce costs.
- The course includes building a second brain using the LLM wiki method (from Andrej Karpathy) to organize knowledge into markdown files with relationships.
Tools mentioned
Techniques
- Context engineering
- Prompt engineering with negative prompting and verification loops
- Screenshot loop for website building
- Progressive disclosure for skills and sub-agents
- Session handoff to manage context window
- Token management: batching, compacting, clearing, and using sub-agents
- Prompt caching to reduce costs
- Agent teams for multi-perspective debate
- Dynamic workflows for parallel sub-agent execution
- LLM wiki method for building a second brain
Takeaways
- You don't need coding skills to build powerful AI agents with Claude Code; natural language and clear thinking are enough.
- Focus on context engineering and iterative feedback to improve outputs and make your AI smarter over time.
- Manage tokens carefully by starting fresh sessions, batching prompts, using sub-agents, and leveraging prompt caching.
- Deploy automations using routines or Modal for scheduled or event-driven tasks, keeping the simplest solution for the job.
Transcript (captions)
In this course, I'm going to take you from a complete beginner to someone who is AI native and can build automations, AI agents, literally anything that you can describe, you're going to be able to build by the end of this course. These are the topics that I'm going to cover with you guys. So, feel free to skip around to whatever pies your interest, but I'm going to go through all of this in order, and I'm going to do real examples and step-by-step builds throughout. So, don't want to waste any time. Let's just jump straight in. So, this whole course is basically assuming that you know nothing and that you don't have a technical background, which if you guys don't know who I am, my name is Nate and I do not have a technical background. But, I've been able to do some pretty incredible things with AI in the past couple years. I've got multiple different businesses that are based on content, education, certifications, events, consulting, and all of that is powered by a small team who is really, really good at using AI. The whole idea is that one person can do the work that it used to take teams. And I felt that ROI myself. And if you guys haven't, by the end of this video, you will have a very clear path to feeling that ROI and having AI systems that help you do more and that will eventually become the baseline. So, it's great to be getting ahead of this stuff. Okay, so first things first, what is Claude Code? Because I know the word code probably intimidates a lot of people. If you've never coded before, you don't have to code. So, Anthropic, that's the company that is behind this ecosystem, right? Um, the cloud models, Claude Chat, that is probably what a lot of you guys are used to. So, there's basically these three products. The first one is Claude chat and that is where you can talk to Claude in the web or wherever you want to do it on your phone and you just talk to that large language model the AI model and you get an answer. So kind of like a a chatbot. Then we've got Cloud Co-work which is kind of like the next step up. Fun fact, Cloud Co-work the entire product was built using cloud code by a few engineers. It would have taken the team weeks and weeks and much larger team but they were able to ship this in like a week with a few engineers. So very very cool. And cloud co-work is much more for kind of like your knowledge workers, your managers. It's much more of a simple interface to do simple automations and stuff, but cloud code is just the most powerful. And the cool thing about cloud code is like I said, you don't need to know how to code at all. And so I really don't ever use cloud co-work even though you could argue a lot of the stuff that I do in cloud code could be used in co-work. code is just way more powerful and it's where I see the future as far as thinking about building your own agents and just having things that are a lot more agentic for you. So those are kind of the three products, but what's cool about it is they're not that different to actually use. So if you learn one really well, you're going to be able to transfer those skills wherever you go. So don't feel like you're locking in by choosing one of these products. That's why I choose the most powerful product. So if I open the Claude desktop app, what do we see right here? This is Claude chat. You know, I can come in here and I can say, "Hi, Claude." and it can kind of understand a little bit about me. It can see my preferences. Obviously, it knows my name, but this isn't where you're going to get real work done. This is where people are kind of treating this as like a Google search engine or they're connecting their Gmail and helping it, you know, having it help them write email drafts and stuff like that, but it's not true agentic power. And this is Claude Code. What do you see? It's a very similar interface. You just talk to it in chat, but now what happens is it's able to access your local files. As you can see here, I can choose a folder to actually work within, whether that's my desktop or my downloads or my Herk 2, which is kind of my AI operating system, which is a term I might throw out a little bit today. Don't worry about it too much. At the end of this video, I'm going to show you a full course around how to actually build your own AI operating system, but this comes first. The whole point here is that Claude Code is able to work inside of local files as well as touch anything out there online. It can touch your Gmail, your Slack, your CRM. It can touch anything online, but it can also touch your local files, which is really, really important. And the other cool thing to note is that when you're in cloud chat, you know how you guys probably are aware of models like Opus or Sonnet regardless of the model or even Fable. Now, Claude Code is powered by all of those same models. So inside of cloud code, you still use sonnet or haiku or opus or fable, but the code aspect is basically just enthropic saying, "Hey, because you're working with local files, here are some other things you can do like web searches and web fetches and searching through local files that make you a little bit more powerful than cloud chat." So fundamentally, it's not that different from cloud chat. I don't ever use cloud chat anymore. Everything that I would typically do in Cloud Chat, I'm doing in Cloud Code because Claude Code knows everything about me, my business. It can see all my YouTube videos. It can see all of my Slack threads. It can see everything that I'm doing, which makes this feel way more like an employee rather than just like Claude chat, which kind of feels like a virtual assistant, right? I'm not reexplaining myself to Claude Code because it knows everything about me. So, you're probably going to hear the term harness, magenta harness, AI harness. That's what Claude code is. And this is kind of the way that I think about how you build with AI. This three sort of layer circle. At the core, we have the AI model. So, Opus 4.8 or Fable or GPT, whatever model you're using, that's at the core. Then around that, we have the AI harness. So, cloud code is a harness that uses AI opus or other cloud models to power it. And then on top of that harness, you have you. So, your brain, your prompts, your context, your data, your business. That's how it works. So if we make this a little bit more practical with analogy here, we've got the model here. We've got a car and then we've got you. So opus is a model, right? But without this is basically the engine. So we put this inside. If I can make the layering right, we put this basically inside of the car. Wherever you think the engine in this car might be, let's just say it's here. Then this is still not going to really be that useful. It's not going to be able to drive or go anywhere without the human. So the human has to come in here and drive the car. So the human is steering the harness and the harness is powered by the AM model. That might make no sense to you at this point. That's okay. I just wanted to sort of lay out these terms because you will hear these terms the more you get into AI. So just a simple way to think about it because as you continue to evolve and as the tools continue to evolve, you might switch out the model. So maybe you'll be using cloud code, but eventually you might switch this out for a different model or maybe you'll be using the model, but you'll switch out a different harness. Maybe you want to get in a different car and just drive it in a bit of a different way. So they're interchangeable but at the core this is what we're looking at AI harness and you and really the most important thing in this whole picture is you. If you are not giving it the right context then it's not going to be able to do the right stuff for you. So that's what it looks like. Okay. So that is what cloud code is. Now before we start getting into some of the technical stuff of getting set up and you know building stuff I wanted to talk about the mindset because the mindset around this stuff is so important for many reasons. I think the first one is that you know the space changes so fast. new models, new tools, new headlines. The space changes fast. So, how do you learn things in a way where it's not outdated next week? And that's what I want to teach you guys today. That's so important, in fact, that I actually wrote a book about this. It's called Becoming AI Native. And in this book, I go over kind of like throughout the chapters, these 12 big mindset shifts. And so, throughout this course, I'll probably relate back to some of these mindset shifts a little bit. But, I wanted to talk a little bit about mindset before we jump into the weeds of everything today. But before we hop into those mindset shifts, I want to talk about real quick with you guys. Six AI skills that I think every single person needs to master just to basically future proof their careers. AI is real and it's not going away. Just like social media replace newspapers and billboards and Netflix replace cable, AI will change and replace millions of jobs, including yours, unless you learn six important skills. These six AI skills will futureproof your career so that you don't have to try and start a business if you don't want to or switch careers if [music] you don't want to. So, these six skills are going to apply no matter what job title you hold or whatever career you're pursuing. And I can guarantee you the last skill in this video will surprise you because it's the most unique skill, but it does work. So, let's just get started with skill number one, the AI person. So, becoming the AI person. I know that that sounds like super obvious because this is an AI video, but I think that a lot of people misunderstand what that actually means. If you're watching this, you probably feel like you're on the beginning side of AI. And honestly, you probably are because there's so much happening right now. There's always new models. There's always new tools. There's always new agents and workflows, new benchmarks, all of this kind of stuff coming out every single week. But I bet if you went and you talked to [music] your friends or your family or just a lot of the people that you work with, they probably already think of you as an AI person. Or if they don't, you want them to. And that's the point. Being the AI person is relative. It doesn't mean that you're the best AI engineer in the world or that you understand [music] every single AI model and the architecture behind it. You guys probably think of me as an AI person, but in reality, I feel overwhelmed every single day by how much I still don't know. But just remind yourself it's all relative. It just means that inside of your circle you know more than the other people and that matters way more than you might think. I've seen this happen over and over in my communities. People start picking up AI almost like a hobby. So they're playing with Claude, maybe they're testing out codecs, maybe they're messing around with Google V3, building little tools or little AI side projects, automating parts of their job, just running a bunch of experiments. And then what happens is they start showing people and that's usually all it takes. They show someone at work, hey, look at this thing I built this weekend. Or hey, I used Claw to clean up this process. or hey, I figured out a way to make this task, which normally takes me three hours, only take me 20 minutes because of AI. And all of a sudden, that person becomes known as the AI person. And the reason this is so powerful is because companies are about to have a ton of like AI moments. They're going to get access to a new model or they're going to spin up a new internal product or maybe they're going to want to build a little AI task force internally. [music] And when that happens, someone's going to say, "We need someone to lead this." You want someone in the meeting to say, "Actually, I know someone who's really into this stuff." Or something like, "We should ask Nate. you know, he's told me that he's been playing around with all these AI tools. That's how these opportunities open up before there's a formal job title. And that's how people get pulled into better projects. That's how people become more valuable without quitting their job and starting from [music] zero. And the data backs this up. So IBM's 2026 CEO study found that 85% of CEOs said that all functional leaders have to become technology experts in their own domain. Not just the CTO, not just the engineers, not just the IT team, everybody. So whether you're in marketing, sales, finance, ops, legal, customer success, whatever you're in, this applies to you. And the thing to remember here is that it's not just in one department. It's not like cyber security where you kind of have like a new team and then you're done. It's going to seep into every single role and every vertical whether you like it or not. And I know some of you are probably thinking, "Okay, but my role doesn't really need AI and that's your mistake. Your role will need AI because every single role will." So instead of trying to switch careers or learn a completely new job, just take a look at your role. Take a look at what you already do and ask yourself, how do I become faster and better and more useful at this specific task and this specific role with AI? So, I mean, think about it. If you were an accountant when Excel came out and you basically just said, you know what? I'm good. I like the way I do this. I'm going to keep doing all of this on paper and with a calculator, you were done. Like, that was probably your last day at that company, if you said something like that, if you made kind of like that stubborn statement. The people who learned Excel first were just faster. They got through spreadsheets in a fraction of the time that it used to take them. Let's just say from two spreadsheets a week to 10. That's just random numbers, right? But that new level of output became the baseline. And AI is like that, but it's a lot bigger. Cuz right now, being the AI person feels like an edge, but in a few years, it's just going to be the new normal. So, the advantage isn't waiting until someone's forced to learn it. The advantage is becoming the new normal. While most people still think it's optional. So, practically, how do you actually do this? Well, I would say you pick one main AI tool and actually get pretty good with it. So, as of May 2026, recording this video, for me, that's Claude. And I use Claude for my general knowledge work and to build automations. But the exact tool isn't the point. The point is, you need one tool that you're not just messing around with. You're using a tool to actually deliver some sort of ROI. And then you can pick one workflow in your current job. You can take something that you already do every week. And then figure [music] out how you can use AI to make it better or faster. Document what changed, how long did it take before, how long after, what got better, what still needed human judgment. Now, obviously, be smart. Like, don't expose company data or break any regulations. Don't try to automate something at work without getting like permission about it. And if your company has guidelines and you can't use Claude, then that's actually another opportunity for you to [music] look at because you can go dig into what those regulations are and you can figure out which tools you actually could use. And that alone shows that you care. But I just want you guys to remember that you don't need to [music] change careers. You can just find the AI native version of the career that you already have. So that's skill number one, become the AI person. But skill number two is where a lot of people are going to mess this whole thing up because the more you use AI, the more tempting it gets to just trust the output and say like that's good enough. And that's where skill number two comes in, which is taste and judgment. As AI gets better, it gets easier and easier to just trust the first thing that it gives you. And I saw this joke the other day that was on one side, we had a person with a bullet point and they were using AI to turn that bullet point into like a super professional structured email to send to the team. And then on the other side, we had that team and they were using AI to turn that structured email into just one bullet point. Now, it's funny, but it does also kind of create the perfect image of where work is going if we're not careful. You know, everyone's transforming things, but is everyone reading it? And that's dangerous because when you first start using AI, you review everything, right? Like you read every word, you double check the claims, you make sure it sounds like you, but the outputs start getting pretty good and then you get more comfortable with it and you just kind of let your guard down and that's the trap. And sometimes the giveaway is really small like [music] m dashes. You know, AI is notorious for putting m dashes in everything because it's been, you know, trained on so many white papers and formal documents. And so like for me, I've basically never manually written or typed an M dash in my entire [music] life. So if something goes out for me with five m dashes in it, people who know me are going to look at that and be like, "Okay, Nate obviously didn't write this. This is AI." And the problem is the second they think that it changes the way that they interpret that entire message. They start wondering, "Did this person actually read this? Is any of this true? How much of this is actually them?" And that's where taste comes in. And just to be clear, I'm not saying that I don't use AI to write or that you shouldn't. I think everyone should. It's just about taste. But anyways, this issue comes up for me all the time with video. So AI helps me make motion graphics that are honestly way better than what I could do by hand. They're way faster. They're cleaner, they're more polished, but it doesn't always get right where the motion graphics should come in or how long they should stay on screen or the visuals and like what's explaining and if it's distracting or if it's helpful. And that is still my job to watch the whole video back and give feedback. And that's going to be true in every field. AI can write the sales email. You still need to know if it'll annoy the prospect. AI can draft you the HR memo, but you still need to know if it'll make the employees feel weird. So, how do you actually build this skill? First, you should study the best work in your field. If you're in sales, study great sales emails. If you're in marketing, study great landing pages. Next, start saving examples. So, build a library of stuff that you actually like and stuff that sounds like you. And when something's good, don't just say, "Cool, that's good." And just copy and paste it somewhere else. Ask it why. Ask what made it good and ask what makes it clear and ask what makes it trustworthy and tell it why you think it's good and tell it what you like about it. Third, every time you correct AI, you feed that correction back into the system. So, the feedback loop is for good things, but also for bad things. If AI writes something and you change five things, say, "Hey, here are five things that I changed. Here's why. Update your instructions so that next time it's closer." And that's how you actually train the system to better understand your [music] taste. Because at the end of the day, AI can generate the work. Taste is deciding what deserves your name. Because remember, if you produce something with AI, your name is signed to it. Whether that is something that's really, really good and the whole team loves it, you [music] will get credit for it. Or if it's something that's bad, you will take the blame. It doesn't matter if AI wrote it, doesn't matter if you wrote it for that piece of [music] work because your name is assigned to it. So now the question is, how do you actually get AI to produce better work in the first place? Because if you're just typing prompts and just [music] crossing your fingers, then you're leaving a lot on the table. So that's skill number three and it's something that you can apply the second you close out of this video. And that skill is becoming a context engineer. So you might have heard the term prompt engineering. This was a huge thing a couple of years ago. The whole idea of prompt engineering was that if you wanted a better output from an AI model, you had to give it a good prompt. You had to give it a role, clear instructions. You had to tell it the end state. You had to give it examples. You had to tell it what to do and what explicitly not to do. But prompt engineering is getting less important over time because the models are just getting so much better on their own. Even Andre Karpathy, who's one of the goats of AI and actually just joined Enthropic, called context engineering the delicate art and science of filling the context window with just the right information. So translation in layman's terms, prompts are how you ask. Context is what your AI actually knows. In context engineering is way more durable than prompting because no matter how good the models get, they still need to know what's actually in your brain. So what's going on in your business, what's on your calendar, what your priorities are, stuff like that. So here's my personal example. I've built what I call my AI operating system or my AI OS. And [music] basically, it has pretty much all the context that's in my head. It can see my meeting transcripts. It can see all my YouTube videos. It can read through my DMs and channels in ClickUp and Slack. It can pull my emails. It honestly knows what's going on in my world better than I do because it can recall everything instantly and perfectly. And I can't do that. So, it's kind of like this running joke that if someone couldn't get a hold of me, they should just message my AIOS and it would actually give them an answer that's better and faster than waiting for me to respond. And that's the point you want to get to where an AI has so much context about you that you can say something like that. So, how do you actually start that? Well, the simplest move, stop opening Claude or ChatGBT in a blank chat. Instead, spin up a custom GBT or spin up a Claude project and feed it real context from whatever you're working on. So, say you're running a marketing campaign for a new product launch. Don't just open up a fresh chat every time you need help with ideas. Spin up a project, drop in documents with your product details, your marketing calendar, add copy that's worked well in the past, add copy that's flopped in the past. Now, the AI is actually working with that context, not generic best practices. And the analogy I keep coming back to here is a summer intern. When a new intern shows up at the company, you have to sit them down and kind of onboard them, right? Like you have to explain what the business does, walk them through who's on the team and who does what. You have to tell them what current projects matter. And only after they have all that context can they actually contribute in a meaningful way. And AI is the exact same. And without the context, it's just a smart intern who's guessing. And remember, the context you're giving for the most part is data that's not publicly accessible. The context about your subject matter expertise, your brain, your IP, that's what makes the outputs unique. If everyone's using that same model and asking for the same things, then everyone's outputs will look the exact same. So your context is really, really important. So just remember, garbage in, garbage out. If you give your AI bad data and no context, then you're going to get a very generic output. So that's skill number three, become a context engineer. Now, skill number four is one of the most underrated skills on the entire list. And in the AI era, it might be the biggest separator between the people who win and the people who get left behind, and it's iteration speed. Now, if skill number two was about knowing what good looks like, this skill is about getting there as fast as possible. So, the two skills kind of work hand in hand, but this one stands on its own because in the era of AI, the people who iterate fastest are the ones who win. If you can move fast without sacrificing quality, you're just going to outperform everybody because every iteration is more data. Every iteration is a chance to learn what's working and what's not and a chance to make your skills and your agents and your prompts and your context, all of it better. The analogy I always go back to here [music] is like you're teaching a kid to ride a bike. You can't just chuck a kid on a bike and say, "Have fun." And expect them to go ride a mile. That's not how it works. You would put them on the bike. You'd maybe put one hand on their back. You'd hold the handle and you'd start walking with them. You would feel if they were leaning left and correct them. You'd say, "Hey, you know, shift your weight over to the right a little bit. You're helping them calibrate. And after each run up and down the driveway, you continue [music] to calibrate. You continue to iterate and adjust. And the more time that that kid spends on the bike with your guidance, the more that you can start to slowly let go and eventually you take off the training wheels and one day you give them a little push and they just ride and they're pedaling and they are doing great." And that's exactly how building with AI works. You very rarely can just oneshot something. You use the data and you feed it back in and you make it better. And the thing is once you've taught one kid to ride a bike, teaching the next kid is easier and teaching the third kid's easier. And by the time you're teaching your 15th kid how to ride a bike, you've pretty much got the process down [music] to a science. And now obviously every use case is different, right? Like some agents are more complex than others and and they don't always get built the same. But the idea of your process in building agents gets better every time. So hopefully you guys get the point that I'm trying to make here. Remember earlier that little example I said of like let's say people are typically producing two spreadsheets [music] a week and then after Excel they move that baseline up to 10. The faster you can iterate, the faster you're going to be able to produce things, which means your new baseline is going to be higher than everyone else's baseline as far as like units of output. So how do you actually train yourself to be able to iterate and move faster? This part may sound silly, but the first thing I think is to master keyboard shortcuts. Stop using your mouse for every little thing and honestly stop typing everything, right? Like use voice input. It's way faster than typing. And we actually have a voiceto text tool called Glido that I use literally every day. So if you want to check it out, links in the description. But the bigger move is rapid prototyping. Don't sit there trying to plan the perfect [music] version. Just build the ugly version fast. See what breaks, fix it, and iterate. That's the whole idea of getting out a P or a proof of concept. Now, there's another half to this skill that's just as important, which is knowing when to stop iterating. Because when you're building AI tools, it can feel like there's no such thing as a finished product. [music] I've been there. There's always a nice to have. There's always one more feature you could add. So what you have to do is give yourself a north star. You have to tie one automation to one very specific business metric and you have to define what done is. You have to define what done looks like before you even start building. So if it's a customer support automation, tickets resolved per day. If it's a sales automation, maybe it's qualified appointments set per week. If it's an ops automation, maybe it's refund percentage going down by X%. So pick the metric, build until you hit it, and once you hit it, move into maintenance mode. Obviously, over time, you can probably find ways to improve it and maybe improve the metrics even more, but the heavy lifting is done. So whether you're building automations for yourself or for a client, a clear definition of done is what keeps you from scope creeping on yourself. And that's skill number four, iteration speed. Now skill number five is going to feel a little bit different and it's inspired by Iron Man. So this skill is building your own Jarvis. So you guys have seen Iron Man, right? Tony Stark doesn't sit at his computer typing prompts into Jarvis all day. Jarvis is already always there. He runs in the background and he notices things and he pings Tony when something needs attention. He'll even kick off tasks before Tony even asks. Now, this is different from skill 3. Context engineering was about teaching your AI what you know. Skill number five is about teaching your AI to act on what it knows without you having to be the trigger. So here's the way I think about this. Imagine you build an automation that only runs when you explicitly fire it off. That's great. It's going to make you a lot more productive. But if you're not around to trigger it, nothing happens. Now imagine you build a system that fires on its own. While you're in a meeting, while you're on a walk, while you're taking a nap on the beach, that's real leverage. So the move here is to do an audit of your day. What things do you do every week that get triggered by something predictable, meaning maybe a specific type of email coming in or every Monday morning or every Wednesday evening or every time a new lead lands in your CRM? Every one of those triggers is something that you can actually hand to a system and tell it to do X, Y, and Z when A or B happens. But here's the catch. The second you take yourself out of the loop, the risk obviously goes up because you're not sitting there watching it and making sure nothing goes wrong. There's no catching the mistake before it reaches a customer or pulls the wrong data or sends the wrong message to the wrong list. So the moment you remove yourself from the process, the system has to be pretty airtight and pretty battle tested. Which is exactly why a lot of people screw this up. The second they hear Jarvis or an always personal AI assistant, their brain jumps straight to building an AI agent for basically every function. Whether that's a new email or an end of week report. A lot of people just jump straight to an AI agent. So the real skill here is knowing when something needs an AI agent versus when it just needs a simple workflow that doesn't even use AI at all. So I think about this like a vending machine versus a slot machine. A vending machine is deterministic. You put in a quarter, you hit E4, you get a Coke. Same input, same output every single time. A slot machine is nondeterministic. You pull the lever. Sometimes you win, sometimes you lose, sometimes nothing. So AI agents are slot machines. And essentially, like every time you talk to an AI, it's almost like you're gambling. Like not really when you put the right harness and context in place, but you never know what's going to come out the other side. Agents are really powerful when you need deep reasoning and you need, you know, variability, but they cost more. They fail more often in unexpected ways. So they introduce more risk. But if you have a simple, you know, if this, then that, that's a workflow. And that's just a vending machine. Predictable, it's really cheap, and it doesn't break. So if your task is something like every morning at 9:00 a.m., pull last week's revenue from Stripe and post that in Slack, that does not need an agent. A simple workflow could do that in 5 minutes and basically never fail. But if your task was something like read these incoming customer emails and understand what they actually want and draft a tailored response, now you need some AI in there because the input is messy and there's reasoning and you have to generate some sort of content. And honestly, this is the elite version of being the AI person that we talked about at the start. Because in a world where everyone is shouting AI, AI, AI, the person who can actually step back and say, "Hey, we don't actually need AI here. We can solve this cheaper, faster, and with way less risk." That person stands out way more than the one who's cramming AI into every single task. So being the person that has that take signals that you actually understand the business problem, not just the AI hype. When you're building your Jarvis, ask yourself two questions for every task that you want to automate. First one, do I actually need to be the one triggering this? Or can the system fire this off on its own? And second, does the step actually need AI or could a simple Python script or no code workflow do it at a fraction of the cost with less risk? And what you want to do is default to the simplest thing that gets the job done. Because the people who win in the AI era aren't the ones who are building the fanciest agents with hundreds of tools and hundreds of sub aents. They're the ones building systems that run quietly in the background, costing them almost nothing and doing real work whether they're there or not. So that's skill number five. But the final skill, I can guarantee is something that you've never heard of. At least not in this context. I'm talking about unemployment insurance. And no, I don't literally mean taking out insurance. Rather, I mean creating your own insurance. This might be a bit of a hot take. Not everyone's going to agree with me on this, but I'm bringing it up because I'm really confident this is going to become way more normal over the next few years. And the skill is building multiple income streams using AI so that no single employer or client can take you out. The old career model was basically like one job, one income, a 401k, maybe a few investments. But basically, all your eggs were in one basket. And if you got fired, you were kind of back on the hunt. You were polishing your resume, applying to 100 jobs, hoping somebody bit. And this new model that I'm talking about that I see emerging is job stacking. Your day job plus a couple of AI powered side income streams. I've already seen a ton of people running multiple remote jobs, you know, part-time gigs, side projects, and stacking that all to equal way more income than they'd ever make at just one full-time job. I'm not saying that every one of you guys should just go quit your full-time job and do this. I'm saying that it's already happening and it's about to become way more common because AI lets one person do work that used to take a team of five. Now, the thing I want to hammer home here, you don't have to stack five income streams in completely different domains. That's how people end up burnt out and broke. The better version is one passion with multiple branches. I'm a really, really strong believer that to be successful at anything in life, you have to enjoy it. You have to have at least some kind of passion for it. If you're chasing AI for the wrong reasons or you're going after something because someone said there's a lot of money in it, then people are going to be able to see right through that and it's going to be really hard to be successful. So, what I want you to take out of this is to figure out what motivates you. Figure out what you're actually passionate about. And that's where your north star comes from. I've got a few different income streams myself. And what's cool about it is that they all stem off of my same north star. Same theme, same expertise just packaged in a few different ways. For example, you've got your career, that's your foundation. your expertise about that career packaged into maybe a course or a niche newsletter or blog or microsass or maybe even some consulting on the side. It's the same domain, but it just takes different [music] shapes and that's how you avoid the biggest trap with this whole idea which is distraction. When you're starting, just pick one and go hard until you have momentum under you and then you can sort of branch out. Now, a couple quick caveats to mention here is once again be smart, check your employment contract, watch out for non-competes, disclose whatever you're doing on the side if your company requires it, like don't do anything sketchy and don't burn your day job chasing the side thing and be safe. But how do you practically do this? Well, honestly, this really depends on who you are as a person, but if I had to give a default move, I would say building in public. Experiment with AI tools, build small things, and share what you're learning. Document the wins and losses. Build a tiny brand around the work you're already doing. Because the second you start posting, you become discoverable. That's how opportunities show up, clients show up, job offers show up, people want to work with the people actually doing the work. And this is also something interesting to think about. The world is shifting in a way where humans are using AI for almost everything, right? Which means when humans go to search the internet for something, they're probably going to do that through some sort of AI interface. Which means if you don't exist basically at all, somewhere where an AI can find you and find information about you, then it's going to be a lot tougher to be discovered. Now, if building in public isn't your thing, that's fine. You just have to find your own version. Maybe it's a quiet consulting practice, niche newsletter that doesn't require your face. Maybe it's a product that you build and sell without ever showing up on camera. Medium is completely up to you, but the point is you start building something that's actually yours. So, those are the six skills that I'd recommend learning and developing to futureproof yourself in the AI era. I'm a strong believer in adaptation and survival of the fittest. So, as long as you keep up with the changes and developments in the space that matter for your northstar, your ability to earn and live will always be protected. And now that we have discussed those six skills, keep those in mind as you work your way through the rest of the course and the rest of these mindset shifts. Everything loops back to those. So, now let's get back to those mindset shifts. The first thing is that AI native isn't what you know. It's not how much expertise you have or how many models you can name. It's about what your hand reaches for. So throughout this course, what I want you to think about is how would you do this manually? When you know that you need to respond to an email or that you need to analyze a report, what do you do? You probably open up the tab on your browser or maybe you even have it bookmarked and you're constantly switching between tabs and context switching. But being AI native means, okay, rather than doing this manually myself, let me default first to doing this with AI, doing this through cloud code, doing this through my other tools, using AI to do something like research and analysis before I give it my first pass. That's how someone becomes truly AI native and way more productive. I hardly ever leave cloud code. Most the day when I'm working, I'm working inside of this interface right here because it just makes me way more productive. And then the next one that I wanted to call out, and like I said, we'll probably revisit all these, is number four. Don't quit in the dip. The payoff is the climb. And here's what I mean by that. Let me just make a quick chart here. Whenever you decide to learn something new, there is typically a short-term cost that you have to bear. Whether that is because you're a bit overwhelmed or whether it's because you have to learn a new skill or set up a new system, whatever it is, there's usually a short-term cost you have to bear. And that discourages a lot of people. So let's say you start learning, you know, you start taking this course, you start getting a little overwhelmed. Do not quit. Do not click off the video. At least save it for later and come back to it because like I said, what happens is you start learning, right? And a lot of people expect that the learning is going to be linear like this. They expect this is how their progress is going to look. But typically what happens is their progress looks more like this and it becomes exponential. And so this gap right here, this is where people end up dropping out. they get overwhelmed and they quit here before they start to get all of the actual exponential benefits of learning the thing and implementing the new technology. And look at all this green that you're actually going to get when you keep learning and you keep building. Another way that I like to think about it is let's say on this range, right? The old way of doing something is maybe getting you results that are about here. And what happens is the dip that I'm talking about when you start to learn a new method. You may feel slower in that week and you may feel like you're doing it worse in that week because you're so used to the old manual way. But what happens is is that short-term dip, maybe you're dipping in 20% productivity. Is that dip worth, you know, maybe the 60% productivity that you ultimately will have? In most of the cases, the answer is yes. But this is where people drop off. And that's what I'm trying to prepare you guys for. Do not drop off in the dip. Do not drop off in this gap right here. And because I'm designing this course for knowledge workers, managers, regular people that don't have coding backgrounds. Think about it like this one overarching rule. You are just a manager. You're managing AI agents. What does that mean to me? Think about it like if you've ever managed an employee, which a lot of you guys probably have, but if you haven't, this is typically what it would look like. First of all, you get them onboarded. You let them get to know you. You get to know them. You let them get to know your business a little bit. You don't want to overwhelm them. You don't throw them 10 products on day one. You slowly phase them in until you start to feel a little bit more trust. But that doesn't mean you just let them run. Your job is to very, very clearly tell them, "Hey, this is what you need to do today. This is what good looks like. This is what bad looks like." And then when they finish their job and they give you something, you don't just pass it along or accept it as is. You review it. You look at it. You use your judgment. You use your taste. And then you say, "Hey, here's what you did good and here's what you did bad." Now take my feedback and iterate again and update your instructions. You know, remember that I told you this so that next time it's not bad and next time it's even better. And that doesn't mean it's going to be 100% on the first pass, but it means every single time that you get a deliverable from your AI agent, that's an opportunity to improve the system. And the cool thing is all of this improvement, all of this instructions, everything I'm explaining right now and everything for the rest of this course, it's just natural language. So if you can think clearly about what you want, which humans are pretty good at, and you can describe what you want pretty clearly, which once again, humans are pretty good at, then you will be good at managing AI agents. All right, so let's move on to number three, which is installing and signing in to cloud code. So you can just go ahead and Google cloud code install, right? You can click on the quick start docs, and then you can pretty much figure out right here how to get a cloud subscription because you do need a cloud subscription to use cloud code. And then how do you actually install it? And there's a few ways to do this. If you want to use one of these commands in your terminal to install cloud code on your device, that works fine. And by that I mean you would open up your command prompt or your PowerShell or, you know, whatever it is on your operating system and just run these commands. You could even have Cloud Chat help you out with this if you're having trouble for some reason. But it's super easy. And what I would recommend is getting the Claude Code desktop app or just cloud desktop app. So Google that, click on this right here, and then download for your operating system. So for me, I'm on Windows and I would download this, run the wizard and then when you open up Claude, it will look something like this. And you're just going to go ahead and get started. Now, this is where you are going to, like I said, have a paid plan for Claude Code. You can start on this pro plan. As you can see, you get Claude Code and then you can upgrade that later if you want to max the $100 a month plan or the $200 a month plan. I know that sounds expensive, but think about this. For 200 bucks a month, you can get basically a full AI employee, which is the cheapest employee you might ever get for the amount of work you can do. For reference, um, you know, a good project manager or a good software engineer could cost you way upwards of $100,000 a year, whereas this is only going to be 200 bucks a month, which is very cheap. So, start with Pro and upgrade later as you need. And once you have that account, then all you have to do is actually sign in on the Claude desktop app. All right. So, now that we are set up, let's talk about where to run Cloud Code. So, I just showed you guys how to use the cloud desktop app, right? You can come in here and we can talk to Claude chat right here. I can say something like hello or sorry, it's not cloud chat. This is cloud code and this is the cloud desktop app. So, I'm going to be using this throughout the course because I think the interface is super nice and we can manage all of our different projects and our chats on the lefth hand side. So, this is what I will be using today. However, I will say a lot of the times I do like to use this in VS Code. So, VS Code is just a simple IDE. It's completely free to download and it lets me use cloud code in the terminal like this or I can even use the uh cloud code extension which looks once again a little bit more userfriendly. So the point I'm trying to make here is there's a lot of different ways you can run it. Other YouTubers run it different ways, your friends might run it different ways, but under the hood it's basically all doing the exact same thing. So don't stress too much about where you use it. If later on in 2 weeks you want to switch to VS Code, you can do so and nothing will change. All of your files and projects will still be there. all of your sessions, all of your apps, whatever you built, it's still there. It's just the way that you actually interact with it. So, don't stress about it too much. Like I said in today's video, I am going to be using it right here with the Clawed Desktop app. Okay, so earlier I said that this can work with your local files, right? But what does that actually mean? So, if I open up my file explorer right here, you can see that I've got, you know, my downloads, my desktop, a bunch of other folders, pictures, whatever. And Claude Code is able to navigate through all of this, edit these things, move them around, find things for you. So, just as a super simple example, right here, I have AIS Live Black, which is just a logo, right, for our upcoming event, and this is in my downloads folder from a few weeks ago. Let's say I knew that that was there, but I forgot exactly what it was called or how to find it. I could real quick just say, "Hey, so I know that I have the AIS Live logo, the black version, somewhere in my downloads folder. could you real quick just find that for me and then you know just help me pull that up. And so what happens when you actually send off a message to claude code is it will tell you what it's doing. So right here it says searching AIS live. That means it's searching through my um local files and it's searching for these terms AIS live logo ais you know BB black AIS live. It found this right here. It found the AIS live PNG. Then it says, "Okay, there's it with the blue live and the red dot, which means it used its vision to look at it to verify that this actually is the real logo that I'm talking about." And now it's using something called PowerShell. So, it's basically just running commands. And it said, "Pulled it up. Here's the file. It's in your downloads." There's also an AIS Live White sitting right next to it. Do you want me to copy these into the brand assets so that it's in our project here? Or, you know, like what do you want to do with it? And basically, if I wanted to just find it again, I could just copy this file path right here. I could then go into my file explorer and I could just come in here, paste that, hit enter, and it will open up the picture. So now I was able to locate exactly where that was. But yeah, if I wanted it to organize my downloads folder or organize all of my documents, it could do so. Now, another quick example, it can also create things for you like Excel sheets, Google Sheets, Google Docs, HTML, um, documents, websites, apps, anything. So here's a quick example. I gave it a SLG goal prompt which I'll talk about later in this course, but that basically just means that I'm able to set a condition and Claude will keep working until that condition has been met. I mean, that's so that's just an employee, right? So, I basically said, I want a quarter 2 assessment of my YouTube channel performance. This means that you have to go to YouTube, pull the data, and then put everything into an Excel sheet. And I don't only want you to display the stats. I want you to do deep analysis as if you are my master content strategist. an analyst. So then what happens is it reasons through and you can see here it even took screenshots to verify that everything looked good and to verify that everything was accurate and then it comes through and it gives me this Excel sheet and as you can see it put it here inside of my Herk 2 project in a folder called projects in a folder called YouTube Q2 2026 assessment and then it gave me this Excel sheet which if I pull this up this thing is pretty legit. We have a start here page with a bunch of you know just basically onboarding us to this doc. I can see the executive dashboard with my real-time stats, subscribers, my performance from the quarter, things that mattered. I can look at per video scorecard with length, views, views per day, watch hours, all these other stats, monthly trends, content pillars, format and length, audience, and traffic. So, this is insane. How long would this have taken you to manually go pull out, you know, 75 videos, put all the analytics in here, color code it, design it, do all of this, and this literally took my AI agent about 10 minutes right here inside of Cloud Code. And once again, all I did was I used my completely natural language. All of you guys could have instructed Claude to do this. Okay, so we're flying through here, just getting through a lot of the beginning stuff, and hopefully you guys' mindsets are getting in the right spot and you're getting excited. Let's talk a little bit about prompting. What exactly is prompting? Prompting is the way that you talk to your AI in a way that actually helps it achieve the goal that you want. Now, there's a few levers to pull here when it comes to prompting. And it's really not that complicated. You know, we used to have this term, which it still exists, but there's this term called prompt engineering, which is basically the art of designing prompts to get your AI agents to actually do what you want them to do. Now, prompt engineering is becoming a little bit less important over the years. It's still very important, don't get me wrong, but the the models are getting so much better where the prompt is less important. It still is important, but over time, I think it will become less important because the models are getting smarter. But generally, the things that I like to tell my agent are the role. I like to define, hey, here's who you are. Here's what you're supposed to do. And, you know, context. So, you are a master content strategist like you just saw in that example. you are helping Nate who runs a business doing X Y andZ and here is what's important to Nate's business these X Y andZ metrics and here is the avatar for Nate's business so giving context on you know the background so context and background I should say because not only is the background important but specific context so I need you to help me run you know a Q2 an analysis on my YouTube channel so that I can look at all the stuff and I can make Q3 even better example instead of saying hey help me write this email to my boss say, "Hey, help me write this email to my boss. I need you to, you know, sort of tread lightly here because I've gotten in trouble twice in the past month, and I'm asking for more time off, and you know, he's a really great and understanding person, but I just feel like a little bit guilty for asking for this time off, so that's why I need help writing this email." Giving your agent that context is going to make it understand your actual desires much better. So, you're not sitting in this place where you're like, "Okay, AI sucks. It didn't give me what I wanted." it's probably because you didn't give it clear enough instructions of what you actually want. Now, the next thing I like to do is I like to negative prompt. Basically meaning what not to do. So, if you think about it like you're instructing a student or, you know, a kid who's trying to learn a new process, you have to tell them what not to do because they're curious and they're going to try different things unless you explicitly tell them not to. Now, if you were telling someone like, I don't know, a 45-year-old how to make scrambled eggs, you probably wouldn't tell them not to put their palm on the stove top because, you know, they've been around, they have experience, they know not to do that. But an innocent mind probably doesn't know that. So, you would say, "Hey, don't ever touch the pan. It's going to be very hot." So, negative prompting, I found, has really helped make sure I keep the agents on the guard rail that I'm actually, you know, trying to keep them on. And then another thing that I really, really like to do is add verification. Basically, the idea of, you know, and I'm actually going to type this out because it's so important in all caps. Make the AI prove its work. Is that the right its? That might not be. I think in this case, that's the correct it. But either way, you guys know the point I'm trying to make. Make the AI prove its work. Think about it like this. Let me make another one of my little axis charts here. Okay. So when you ask AI to do something, what are you ultimately looking for is you are looking for it to get you an output that is 100% perfect. Now realistically that doesn't happen very often. So what happens is on the first pass you're maybe getting somewhere around 60% of the way there and then what happens is you give feedback like we talked about earlier and then it tries again and now you get a little bit higher and you just keep doing these manual iterations of feedback until you eventually get to this point where you're satisfied with the work and maybe you take it home that last 2% or 1%. Now this is because it is not the one verifying its work. You're the one verifying its work. So all of these steps are keeping you in the loop. But what if you could actually make the AI check its own work so that on the first try now it's maybe getting and that's not completely aligned. Let's try that again. So that on the first try it's maybe getting you 80% of the way there. And then you the human have to iterate two or three times and then you're there. And this gap is what you're trying to close here by allowing the AI to prove its own work. So what could that look like? Let's say you are building um a website and you want to make sure that the form submission works and that it doesn't accept, you know, bad versions of an email. For example, if people are submitting their emails, it has to be, you know, an actual at something domain. Well, you can have the agent open up the website and test it a 100 times and test that, you know, none of these edge cases sneak through and then it proves to you, hey, here's what I ran. Here's why I'm confident. And what what you'll find is when you do stuff like that, when it's trying to prove it's work and it finds bugs, it will fix the bug and then keep testing and then fix the bug again and then keep testing. So the way that you do verification is obviously different for whatever the task at hand is, but every task at hand has some sort of verification. Just think about it like this. If a human gave you this work, what would you do to approve it? Would you just read it through a bunch of times to make sure there's no grammatical errors? Would you actually open it up and use it? Would you make sure that there are no, you know, elements out of bounds or something like that? Whatever you would do to verify it, chances are you can tell cloud code to do that to verify it. So those are kind of like the main four things just to keep it simple that I'm always thinking about when I am prompting my cloud code to do something for me. All right, so let's talk a little bit about tokens and models. So what is a token? Well, a token is basically what we are being built for. So when you pay for credits on some account, you're paying for credits. When you are paying for your AI model usage, you're paying for tokens. A token is essentially how AI interprets text. So maybe four characters is a token or maybe a punctuation mark is a token. It's not a deterministic rule of what a token really is, but roughly 3/4 of a word or short words. So maybe in this scenario, the sentence cla code helps you is four tokens. Now you don't need to know exactly this like that's not important if you can identify hey that's one token that's 12 tokens. What's important is that you know the pricing. So different models cost different amounts and they all have different pros and cons. So if we look at for example right now in the current you know July of 2026 clawed models with their tokens. Haiku is fast and cheap. So for certain scenarios you only need Haiku because it's fast and cheap. It's $1 for a million input tokens and it's $5 for a million output tokens. Sonnet 5 is $3 for a million input tokens and $15 for a million output tokens. And this is a very balanced model. And Opus 4.8 is the most expensive model right now besides Fable, which is even more expensive, double the cost of Opus. But Opus 4.8 is $5 for a million input tokens and $25 for a million output tokens. Now, yes, you guys are noticing there's input and there's output. And the output tokens are more expensive. So, what is the difference there? Well, let me open up a new chat real quick. Or actually, let's just go to the one where I said hello. So, every time that I shoot off something, my prompt goes into the model. So, this is where we're being charged for Opus, for example. Actually, let me switch this model back to Opus. This is where we're being charged $5 per a million input tokens for this. Now, everything that it spits out, all of these things, all of these commands, every line of text that it gives us that it puts out, that's being charged for Opus at $25 per million output tokens. So, when it is outputting stuff, that's more expensive than what you're feeding into the model. So, for example, if I go back to the YouTube Analytics one where it gave us this Excel sheet, let me ask a quick question. How many tokens did you have to output to actually generate that YouTube assessment Excel sheet? And because you were using Opus, how much real money would that have costed me? Okay, so keep in mind that this is an estimate. But here is what this looked like. So it had to run different scripts. It had to check them out, write up the brief, it had to build the Excel sheet with different actual characters inside, and then it had to output basically all those commands. So they're calling this an average of let's just say 25,000 output tokens. And at the pricing for Opus 4.8 of $25 per million, this basically costed us about 63 to run because of the output tokens. Now what's interesting though is because in this session you can see that we've used about 428,000 tokens out of the a million context token window which I will explain in a bit if that makes no sense to you. But the point here is that we probably sent in and the AI model had to look at hundreds of thousands of tokens because it had to pull so much data from YouTube and analyze so many things and that was going into the model. So those input tokens because typically you use a ton more input tokens. That's why they're build lower. This will all start to click a little bit more when you really start to get your hands on. But I just wanted to show you a real quick example of kind of the difference and understanding that different models have different, you know, pros and cons. fast and cheap, balanced, most capable, but they also come with different prices. Now, keep in mind because you guys are on a clawed subscription, when you come in here and you go to your usage, this is how you're being build. You're not being build per token because you're using this inside of your subscription. In your subscription, you have different limits. You've got a current session limit, which is a 5 hour rolling window. You've got all models, which is a weekly limit. And then right now, we have a fable limit as well. So you can only use, you know, this much fable before all of this would then switch usage credits on top. It's really cool because I'm on the $200 a month max plan for cloud code. And if I filled up every single session, every single weekly limit, I would actually be getting around $8,000 of inference out of my $200 a month plan. So we're getting this on a huge discount right now. So if you are using cloud code or you're using the cloud models or any AI models through API billing, which is through token billing rather than through a subscription, you are paying a ton more for those tokens. So that is something else important to keep in mind here. But don't stress about this too much. You're on a subscription, you're getting a good deal. Just monitor your session limit, monitor your weekly limits. I've got videos coming later and I've got, you know, sections in this course later about context window management and session limit management. So just keep that in mind for later. But I just wanted to break that down a little bit for you guys so that these terms all sort of click and make sense. Okay. The next thing we have here to understand is called the claw.md. So if I just real quick open up this project, right? This is my Herk 2 project which I'll refer to a lot. This is my AI operating system. This is the place where I have basically everything about my business. If I go over here to my files and I scroll until I find my claw.md, as you can see, there's a lot of folders and files inside of this project. There it is. I scrolled right past it. This is my claw.md. So, let me open this up full screen. This is basically the system prompt for my AI agent. So, before I read this, let me just show you a quick visual. So, this is our little cloud code agent, right? And let's say we open up a new chat. So, this thing is completely fresh. It just woke up. And I go ahead and I shoot off a message to this thing that says hi. Right? So I say hi. I don't know why this keeps going green, but I say hi to my AI agent. What it does before it processes this message is it's going to read the cloudmd so that it can basically get, you know, it can orient itself with where we are. So it will read this cloudmd which is bunch of lines of text and then it will read my message and then it knows how to respond more accurately. So, if I go back into this real quick and actually just real quick close out of this file, what you'll see is that when I said hello, it said, "Hey, Nate, ready to go whenever you are." A few things on the radar in case any next AIS live is this Friday and Saturday, July 11th and 12th. CIA opens July 28th. Open threads, highros, link tagging, keep the best of fable, what do you want to work on? The reason it knew this is because it was able to orient itself with my cloud.MD MD and read about my projects and you know what's going on in my business so that it's able to help me out way more specifically. So let's take a brief read through some of the stuff that's in my cloudmd here. So this is me setting up the role, right? 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. That is his number one priority. I've then given it a routing map. So this is where things live. If you want to find things about, you know, his business, his team, his OTAAS, his strategy, go here. Here's the path. If you want to find things about corporate structure, entities, tax, IP, then go here. Voice and style, go here. Course knowledge, go here. Projects, as you can see, I'm just telling it where everything lives. And now it can read through this and it can help me out way more specifically. So, this is something that you'll build over time. I'm going to build one with you guys. Don't worry, just a sec. But this is basically just what it is. It's a system prompt for your AI agent and it changes all the time because remember how earlier I talked about the loop of getting an output using judgment to assess it and then instructing Claude to change so that it doesn't happen again. This is where I would say you know like let's say it gives me this output right let's say it gives me some research brief that was just absolutely horrible. I would then say okay Mr. Claude I read this research brief and I don't like this because you didn't use enough sources. is you only gave me four. Um, you also put a ton of m dashes in here which I don't like. So update your instructions in the claw.mmd so that you don't do this again. So that next time I ask you to do research, you do it better. And then claude will write changes in its own claw.mmd and then next time you talk to it, it will be smarter. So that's how these things just get smarter and smarter as you use them. And by the way, when you guys see a file that ends in MD, all that means is markdown. Markdown is basically just like a a computer language and it really just lets computers understand like headers and bullet points and really just structure like that. So this is markdown when it's rendered nicely for us humans to read. But this is kind of what raw markdown looks like. You can see we use these pound signs to indicate, you know, status and layers and we use these dashes for bullets and everything like that. But MD just means markdown. The same way later in this course you might see a py file which would be a Python file or a txt which would be a text file. So the dot and then the you know whatever comes after that the suffix or whatever is just the type of file. All right. So here's what I'm going to do that I want you guys to do with me. I'm on my desktop. You can be wherever you want but I'm going to create a new folder. I'm going to open up a new folder right here. And I'm just going to say I'm just going to call this knowledge work since that's kind of what this course is about. So, I have a knowledge work folder on my local desktop that I just created. And what we're going to do now is I'm going to open up Claude and I am going to click on the plus um right here, new session. And instead of working in my Herk 2 directory, I'm going to open a new folder. And this is where I'm going to go to my desktop, and I'm going to find that knowledge work folder, and I'm going to open that up, which basically means we're now working inside of this knowledge work folder. Where is it? There it is. Okay. Select the folder. Now, it's going to ask if we want to trust this workspace, which I'm going to do because it says Claude may read, write, or execute files in this directory. So, only proceed if you actually trust the space, which I do. So, I click trust. Now, what happens? Well, let's just start building this thing out. I'm going to say, "Hey, Claude Code, my name is Nate." We're just going to start off conversation like that. Now, there is one thing to keep in mind here is because we're in a new project, Claude still knows a little bit about me. And the reason is because there's a difference between your global cloudmd and your project level. So let me explain that real quick as well. If I go down here, I've got some stuff ready. Okay, so global versus project. Global is something that claude reads every single time and that is at the global level. Whereas project is only specifically in that project. So the example you guys just saw, we looked at this cloud.MD where you know it said, "Hey, you are Nate's executive assistant." This gets loaded in whenever I'm inside of my Herk 2 project. But whenever I'm in this new knowledgework project, if I go over here and I go to my files, this folder is empty. So there's no project level claw.mmd file being read yet. But what there is is a global level claw.mmd. And that's how it knows my name. Well, I just said it, but that's how it knows other things about me because there is a global file. So real quick, I'm just going to show you what the global claw.mmd looks like. And before you get a little bit overwhelmed or stressed about this, like I said, this is something that evolves over time and it really isn't a big deal because you're able to change it so frequently by asking Claude to just change it. And for me, the global cloudMD is just things that I like and things that I don't like. So, let me show you exactly what I mean by that. The way I get there is I go to my PC, I go to my drive, I go to users, and I click on my user. And then there's a cloud folder right here. And then from here, I can open up my claw.md, which is just a markdown file. So, this obviously looks a little bit more um ugly because it's opened up as as markdown in my notepad. But look at this. This is my global cloudmd. These rules apply to every product on your machine. They govern any writing meant for Nate or publishes Nate. So, LinkedIn posts, YouTube scripts, comments, emails, captions, docs, anything. So, I have this AI phrase kill list, which I said, hey, every time it outputs something and I say I don't like how that sounds because it sounds like AI, I say add this to my global claw.mmd. You know, I don't like this stuff. So, it won't say all of these phrases. It will never write this in my LinkedIn posts. It will never write this in my YouTube video scripts or anything like that because this is a global rule. And look at this. It's also just learned other things about me over time. He here's the things he doesn't like. Here's other things that I've learned. And this is just my global claim. It's very simple. So, if you've got specific things about your business or specific things about the way that you like to treat Claude or you like Claude to treat you, then you can put those in your global rules because you're okay with the fact that every single project ever that you do with Claude on this local machine, these rules will be in play there. So, that's kind of the difference between um as I said global cloud.MD and project cloud.MMD. And it's important to keep this in mind because later when we talk about things like skills, there's also the element of is this a global skill or is this a project level skill? Okay. Anyways, this is a new project, right? This is called knowledge work. So, I'm just going to say I'm building a brand new project right here and this is for a course that I'm teaching. So, this is kind of a demo project for me, but I want to show my audience how to set up cloudmds, how to build skills, how to build automations. And so we're going to do a lot of this together, but right now what I want you to do is just initialize with a cloud.mmd and acloud folder. There doesn't have to be anything inside of the cloud. Um, but just initialize with a cloud.md folder and just throw a little bit of baseline information in there for now. And by the way, if you guys are interested in the voicetoext tool that you see right up on screen right here, it's it's very pretty, then check out the link in the description. It's called Glido. It's our tool that we created and it is the fastest and the most private on the market. So check it out. Anyways, as you can see, it is going to start building that for us. So, in a sec, we'll see over here on the folder side, we will see a cloudmd and we will see acloud folder. There we go. They just popped up. So, the cloud folder has nothing, but the cloudmd. Let me open that up real quick. This file gives cloud code the context it needs to work in this repository. Keep it short and current. Here's the project overview, demo project, here's a structure, here's the conventions, and any notes. This cloudmd file will grow over time. So as we go through this course and as we build new things, we will all watch this cloudmd file grow together. So that is just showing you how easy it is to get that set up and that your agent can fix that, edit it, delete it, stuff like that at any time. Now you guys are probably wondering what is this.cloud folder. So let me go back up here and show you that that is exactly what we are going to cover next is the cloud folder. These are basically the first two things that I always set up when I'm working on a new project in cloud code. I have the cloudmd which once again is the rules in plain English and then we have the cloud folder which is basically just think about it almost like a settings folder. It's the config folder. Usually the things that go in here there sometimes are more but the three things that I want you guys to pay attention to the settings.json which has things like permissions preferences the agents folder which is where you can build your own custom sub aents and put them in there and then skills which is where you package up your skills and they live in here so that Claude can call on them automatically. Now, just as an example, let me show you inside of my Herk 2 project what this looks like. So, I'm going to come back over here and I'm going to open up my doclaude, which is right here. You can see that I've got my, you know, agents, the one I talked about. I've got my settings files, and I've got my skills. Now, obviously, there's some other things because this project is massive. And that's why I wanted to call out just those three. And really, the most important one, in my opinion, is skills. We're going to talk about skills later more in depth, but look at this. Every single skill that I have in here is just natural language. So, for example, if I open up this grill me skill, it's just a markdown file. So, if I open this up, it looks very similar to the claw.mmd. It's all natural language and it just tells Claude code what to do in this specific skill. So, that's the exact same way that it works in here with our sub agents. And our settings is basically just a JSON file that shows Claude what it's able to do and what it's not able to do. You can see we have allowed permissions. We have some environment variables up here. We've got things that we've denied. That is basically how this settings file works and you don't need to know how to build this. It will build it automatically and you can use natural language once again. So every single project will have these two things but these two things also live on a global level because once again if you wanted to have you know you have your global cloudmd but then you also have global skills potentially. I only have one right now that's global on this machine but you can have skills that apply to every project. You can have sub agents that apply to every project. So that's the difference between global and project. But these are two things that you always want to get set up when you're building a new project. Okay, anyways, let's keep on moving here. Um, one thing I do want to call out is you might see my claude here switch over to usage credits. And once again, that's because I'm about to go past my 5 hour limit, in which case, if I want to keep going, I will then be paying per token. So, because I'm on the 200 bucks a month plan, that doesn't happen too often. But when I am pushing this thing to its limits, I do hit that. And so if you guys see that pop up on my screen somewhere else in this course in a few minutes, don't be concerned. That's all that that means. So anyways, the next thing I want to talk about API keys and env. So first of all, what is an API? It stands for application programming interface. And all of that really means is it's a method to allow one software to talk to another software. So imagine Gmail sending a letter to claude code. That's via API. So the point I'm trying to make here is remember earlier in this course when I showed you guys this demo where I opened up, you know, this YouTube thing and I said, "Hey, go to YouTube and pull my data." The only reason that it was able to go pull my data from YouTube is because I gave it my API key, which is essentially a password. So if I said, "Hey, go pull Mr. Beast's YouTube data," it could only pull publicly accessible YouTube data. it couldn't pull some of those more, you know, detailed stats that I saw from my channel because I don't have his API key. So, what we had to do was we had to give it access to actually pull that information. And that's when it used this fetch YouTube data py, which py stands for a Python file, and it used that in combination with my API key. As you can see here, YouTube data API. So, that's what I'm going to show you guys now in our knowledge work project. We're going to get set up with an API. So, the example that I'm going to show you guys is Tavi. Tavi lets agents search the web better. You can see here they even have an official Tavi agent skills for Cloud Code, which I'm not going to dive into right now, but the reason I wanted to show you guys Tavi is because you can sign up here and you get a,000 free credits right away, no matter what. So, Cloud Code does have built-in tools for research. So, if I say, "Hey, can you please just research what is context engineering?" And just give me like a one-s sentence example or sorry, a one-s sentence definition. So it will basically because I'm prompting it to research this. What it's going to do is it will probably you see it says finding tools. It's looking through different tools and then it's going to actually search the web using a search the web tool. Query select web search. So web search is one of the tools that it can use. It also has something like a web fetch. But anyways the point I'm trying to make here is cloud code can natively search the web. But if we give it something like tavally it's always good to just get other sources right. So what I'm going to do here is go back into tavi. You can see right here I have an API key which I'm going to go ahead and copy. Now API keys because they're passwords once again do not share them with anybody because let's say I am on a paid plan of Tablety and let's say I paid for 5,000 credits. If I gave you guys my API key, you guys could all take that and spend my money and I don't want to, you know, I don't want you guys to spend my money. So I'm not going to show you my API key in this video. I will because, you know, it's a demo and I'm showing you and I'm going to delete it. But that's how you should treat API keys. You shouldn't be posting them online. and you shouldn't be sharing them across your team unless you know your team is supposed to. So anyways, what I'm going to do is say well not say I'm going to go into my files and you can see that once again we only have these two. So what we need is we need a file called aenv which basically just stands for like environment. So environment variables hey cloud code I want to connect you to tavi and in order to do that I need to give you my API key for tavi. So can you please create in this project aenv file so that I can upload my secret. Now the reason we want to create thisv file is it just it's a safe place to put secrets because they won't get pushed to GitHub. You can see here it said let me also add a dot getit ignore so the secret never gets committed. Now, I'll talk about GitHub more later on in this course, but basically what that is is think about this. When you make a Word doc on your computer, no one else can get that, right? But if you push that up to like a shared drive, then other people can collaborate on it and work on it if you make that public. At least you can still push something to the cloud or push something to GitHub and keep it private. So anyways, the point being if you put something in yourv that will never get pushed to GitHub ever. So basically things that are secret and sensitive put in yourv. So anyways, it went ahead and it created that env as you can see right here. And there's currently nothing in there, but it did give us this placeholder. It says Tableau API key. This is where you would put your Tableau API key. So I'm just going to go ahead and delete the placeholder. Go back into Tavi. Copy this value. Go back into Claude, paste that in there, and then hit save. So now that our API key is in there and it's saved, I can say, cool. So I just gave you my Tavly API key. Go ahead and make a test request to Tavi to make sure that that works. So, I'll go ahead and shoot that off. The dictation tool spelled Tavly wrong. So, let me just go into here and add a correction in the dictionary for the real way that you're going to spell Tavi. Okay, there we go. Anyways, it's going to make a test search request. As you can see here, it made a post request to this endpoint. It searched for what is Claude Code by Enanthropic, pulled the key from the ENV, and got a 200 response. So, all of that means it worked. Here's what I want you guys to notice. I didn't tell it how to do any of that. It went off, it researched Tavi, it figured out the endpoint, which is this thing right here, and then it just made the request, which is awesome. Before, you know, a year ago, if you were still building with Naden or something like that, we had to basically by hand research the API endpoints and, you know, plug all this in by ourselves. But now, Agentic AI is getting so powerful that my simple request saying, "Hey, just use Tavi turns into the agent reasoning, researching, testing, and verifying." So super super cool. Now what would happen if I went into my files and I went into thev and then I basically just changed the API key. So this is no longer a valid API key. That's not correct. I'm going to go ahead and clear out the conversation. So I can do a slashclear command right there. And now the conversation's reset. And now if I say, hey, can you try to use Tavi to search for Lenol Messi? When I shoot this off, we're going to see that it's going to try to use Tavi, but it should come back with like a 400 error. and it's gonna say, hey, you know, like something's wrong with the API key or something like that. Okay, so now it just defaulted to the search, you know, the the default cloud code web search tool, which I didn't want it to do. So, let's try this again. No, we do have a Tavi API key that I've given you. Try to use that. Don't use the clawed native web search tool. Okay, so let's analyze what just happened here because there's a lot of lessons inside. So, let me close this stuff out. We used Tavi, right? We used it with the correct API key and it worked. And then I cleared the session. When I cleared the session and asked for it to use Tavi, it said there's no Tavly tool connected in this session, so I can't use it specifically. Now, what does that tell us? That tells us that Cloud Code just forgot what we just did. It forgot that we just successfully used Tavi. We also see that again when it said, "Okay, I found the key, but there's no MCP tool wired up, but let me try to call Tavi's REST API." It tried. It didn't work. So, it said, "Okay, let me try a different method." that also didn't work and then what it did is it said okay confirm that the you know the API key is correct so that just shows you that it didn't work because the API key was wrong but the other lesson here is that we just used Tavly successfully so why did it have to do all this research once again you know what we would do now is save that somewhere in our project so what I'm going to do is I'm going to fix the API key real quick so I'm going to go back into tablet copy this go back into claude we're going to open up our files go to thev and we're going to replace this once again with the true API key, which is correct. And then I'm going to go back in here and say, "Okay, thanks. You were right. Our API key was wrong. I just fixed it. So, go ahead and test it again." But then the other thing I want you to do is somewhere in this project, save this as, you know, a skill or save this as something because we will probably be using Tavi frequently. And when I want you to do research, I want you to default first to Tavali and then to the default clawed web search tool. So actually don't create a skill. Just put this in the cloud. Denmd save the endpoint so you understand like we've done this before. I don't want you to research it every time and that's how you can keep getting smarter every time I interact with you. So that was obviously kind of a a very messy casual version of my prompt, [snorts] but that's the way I do it, right? I identified something. I found myself repeating something that I didn't want to and then I feed it back in because here's the thing that may not seem like a big deal allowing it to search and remake the request. But what happens is this every time costs you tokens and tokens cost money, right? Cuz they go against your session limit. So the more efficient you can be with memory and with things like that, the more you're also going to be saving tokens. So it tried it again. It worked now that the API is correct. And then it said, "Let me save this setup to cloud.MD MD so I don't have to figure out again and now that's all saved. If I go back into our files and we open up our cloudmd we can now see here that it says research and web search default tavly first the API key lives in thev here is the off method here is the endpoint and here is how all that works. So if we were to clear the memory right now and then ask it to search the web it would actually use tabi and that is how you iterate on your system. Now, the other thing I wanted to talk about real quick is that we right here saw the term MCP, which stands for model context protocol. If you guys have never heard of that, it's basically it's very similar to an API. APIs have lots of different endpoints that can be hit. And MCPs have a lot of different tools that can be hit, but essentially it's the same theory of how can we connect cloud code to QuickBooks or Google Sheets or Gmail or SharePoint. It's all about connecting to other tools via MCP or API or you might even hear later on in this video something called a CLI. They're all basically just methods of connecting to different tools. They all have little bit of different pros and cons, but I don't want to get into the weeds of that right now. There's no reason getting overwhelmed about that. We're just focused on let's connect to the tools that we use every day to make ourselves faster. So, that is going to do it right now for number 10. Let's move on to permissions and settings. So back in this example, as you guys saw, we have a couple things to think about. The first thing is the actual permission mode that we use inside of cloud code. So if I go into here, you can see that we have different modes. We have auto mode, which is the default. We have manual permissions, we have accept edits, we have plan mode, and then we have bypass permissions. And if you don't see bypass permissions, you would go into here, you'd go to your settings, and then you would go to cloud code. And if you keep scrolling down, there's going to be something right here, allow bypass permissions mode. This allows Claude to just do everything. It will never stop and say, "Hey, is this okay? Can I do this?" It will just do everything. And um hence the name bypass permissions, dangerously skip permissions. So, typically being on auto mode works just fine, but there might be some times where you do want it to be able to bypass, but there are some things that you want to be explicitly very careful of. We've all heard those horror stories of agents deleting databases. We actually had something internally where an agent accidentally sent out an email to like 150,000 people with a discount code that wasn't supposed to go out. The reason that happened though wasn't because of a permissions mode like down here. That was because the agent had access to so many tools. And really what you should be doing is like let's say you connect your agent to your CRM and your agent only needs to be able to read it. It doesn't need to be able to delete records or update records. So there's no point in giving the agent that actual tool to be able to do so. So that's where you might want to think about like API keys with scoped permissions and things like that. And what's nice about thinking about scope permissions is it's usually pretty userfriendly on the third party tool side. So here's 11 Labs for example. If you guys don't know what this is, it basically is just like AI voice really. And you can also do like you know you can create voice agents and phone agents and things like that. So, if I come in here to developers and I go to my API keys, you can see I've got a bunch of API keys here. Let's say I'm going to create a new one. Let's say I'm creating this API key and I just need it for sound effects. That's it. And for some reason, it's really high risk where if this API key does other things, it would be bad for the business. So, I would name this key so I am aware of like what it does. And it's always good to name your keys specifically because if you're giving keys to different people on your team or for different agents, you want to see what agents are using what keys, how often, and how much they're spending and how much people are using it. So anyways, that's what we're doing here. Demo sound effect. Right here, you can see that there's an option to restrict this key, which means I can restrict it on credits. So it can only spend a certain amount. So let's say I wanted to only let it spend 10 credits um on a certain, you know, time period, then I could do that. We can also restrict the endpoints. Endpoints is just a fancy word for like what it can do, capabilities, tools. So let's say for this key, I only wanted it to be able to do sound effects. So I would say, okay, you can access that. But for everything else, no access. You know, maybe I want it to be able to read all of this so it can read dubbing, read agents, read projects, read all this. But besides that, the only thing it can actually physically touch and manipulate and do is sound effects. And that's how you give your agents a key that you can actually sleep at night and feel 100% confident that nothing wrong will happen. Because if those horror stories where people delete a database with an agent, if they would have just restricted the ability to delete, then that never would have happened. So that's what I want you guys to be thinking about like this. Would you give your a new hire a credit card and say, "Hey, you can like don't spend anything, but with this card you could." No. That just makes no sense. So treat this once again, what did I say earlier in this video? You are a manager. Just think about this as this is a human. How would I interact with them? What access would I give them? What permissions would I give them? And a lot of the overwhelm about how you think about these agents might just disappear when you shift your mind to think like that. Okay. Now, the other thing we have are some other settings like local settings. So, I'll show you guys a quick example of that. If I go to my back to my Herku project, which is like I said is my main one that I kind of operate in and I go to my umcloud and we talked about our settings living inside of this.cloud folder. So I'm going to open up my settings. What we see here is some environment variables. So cloud code agent teams one. I'll talk about this later in the video during the agent team section, but that's an environment variable. I've also got some other things here that I'm going to blur out. But then I have permissions. And this is me saying here's what you're allowed to do cloud code. You're allowed to do bashes. So just like kind of running these commands. Web search is allowed. Web fetch, edit, write, mcps, mcps, glob, skills, all of this is allowed. But here's what's important. Here are the things you can never do. I I have this project set up so it can never remove anything or delete anything or change these directories or anything here that I would consider risky. And so what I would do is I would put my cloud code on bypass permissions mode. But I felt comfortable about it because it could never do anything that was actually risky. So, that's how I played with the settings in order to actually help me out a little bit with, you know, access. Now, the cool thing about that is I don't understand like a lot of those words, but I just said, "Hey, I'm trying to change my permissions and my settings inside of this project. Here's X, Y, and Z things I want to never happen. Can you help me update the settings file so that you physically cannot do those things?" And then it just worked for me. Obviously, I wanted to test it out a little bit cuz you don't always just take the output, like I said, and just fully blindly trust it, but that's what I did. Now, I will say though, pretty much if you come in here and you go to auto mode, it's going to be really solid. Auto mode was new. So, when I designed that settings file, auto mode didn't yet exist, but auto mode's pretty solid for you guys. When you've opened up Cloud Code and you've been following along with this video so far, you've probably been using auto mode, and that's going to be just fine. So, the settings thing is something to just be aware of, and later you might want to tweak that as you get a little more advanced, but right now, you're probably fine just sticking on auto mode. And then another setting that I want to bring to your guys' attention is down here. So obviously we have the model, right? And you can enable fast mode, which I basically never touch. It costs more and it's faster and I typically don't care about speed too much. We have the different models to choose between, right? So sonnet, haiku, opus, fable. And then what we can also do is the effort, which is pretty interesting. So effort lets you choose between faster and smarter. So, if we move the effort down to medium or low or extra high or max or ultra code, we can play with the effort levels. Now, I will be honest with you guys, I pretty much keep all my models just on high. I don't really like to play with it too much. Typically, what I like to do is switch between models rather than switch between effort. I think that for the most of the knowledge work, you really don't need to tweak it too much. But I will say the unit economics of understanding what is the right model for the specific task in front of you because you're also optimizing for cost is a very important thing to be thinking about as you get more advanced. Right now we're learning the fundamentals. It's not a big deal but as you get more advanced it is interesting to think about this kind of stuff. Look at this for example. We have this chart with GBT 5.5 which is currently OpenAI's best model but you know things move quick. We have Opus 4.8 and we have Fable 5. We're showing all of these models on different effort levels. And on the y- axis, we see the score. On the x-axis, we see the average cost per task. Now, what I want you to pay attention to here is look at GBT 5.5. As effort increases, quality doesn't increase. Score doesn't increase, but cost certainly does. So, that's one where it's like, okay, why would you ever increase the effort? But here on Fable, as you increase the effort, the benchmarks show that your score meaning improves. Now, me personally, when I use Fable on high or max, what I've actually found is that it's slower and it overthinks and it overreasons for no reason. So, I like Fable on high. Opus 4.8 on extra high does significantly feel better, but it's slower and more expensive. So, it's it's kind of a balancing act to play, but looking at these benchmarks is interesting and it's good to know that you have that lever to tweak. But, like I said, for the majority of my knowledge work that I'm doing, I'm just leaving the models on high and that has been working pretty well for me. Okay, now let's talk about something really fun, which is privacy and your data. So, hey Claude Code, can you just do some quick research for me? What does Enthropic say about our privacy? You know, when I'm talking to Claude and the data goes to their servers, like what are they doing with it? Are they training on me? Should I be what should I be careful of? You know, how do I stay safe, especially inside of my own organization and at work? So, the reason I wanted to bring this up is because it is a big question, right? because these closed source models so basically meaning you know OpenAI Enthropic Google those are closed source models because we as consumers don't actually get to own the weights of those models you know we can't install them locally and we can't tune them or anything like that. Now open source models are the ones that you can download locally and tune them but they're not nearly as good as the closed source models. Now the benefit with open source models is that you can own them locally. So your data, your conversation never leaves your home because it stays on your computer. But every single time that I send a message to Claude or OpenAI or Google, it goes to their servers wherever they're running all their compute and then it gets processed and then an answer comes back. And that's why they have these massive, you know, data centers. But the point I'm trying to make here is for the company that you work for or your own business, you should not be sending over private sensitive data. For my case, it's really not that much, right? because I'm making content and I am doing stuff like that. I'm not directly handling people's credit card numbers or their personal identifiable information. But I wanted to bring this up because for some of the clients that I've worked with, they had very strict requirements. You know, like we couldn't do anthropic stuff for them. We had to do on-remise deployments and we had to think about security in a much different way as far as like encryption and stuff like that. But that's why I wanted to bring this up. I'm not going to dive into deep deep deep deep about like encryption and on-rem right now in this course at least, but I wanted to bring this up so that nobody here gets in trouble because they watch this course and then they're all of a sudden putting a bunch of company documents and legal contracts into AI when their company would get them in big-time trouble for doing something like that. So, be safe. Think about what's allowed inside of your industry, inside of your organization before you start chucking in documents into something like Claude. Aha. And look at this. I'll research this with Tavly first per hour clawmd setup. But anyways, I'll just go over real quick what this says. It depends entirely on which cloud you're using on consumer plans, which is, you know, the free pro max, not a team plan. As of the policy change effective October 8, training is opt-in, but it's a forced choice. So, you basically had to toggle this on or off. You can check this right now by going to your settings, going to privacy, going to help improve Claude, and then you can toggle it on or off. Now, just because they claim that they're not going to train models on your data, they still have that data. So, you know, that's why even if you have that toggled off, check with your own organization. Cool. So, now that we've covered probably, of course, the most fun and exciting thing of this course, let's just talk more about connecting your own tools because that's how this stuff gets super super super powerful. Okay, so in my Herk 2 project, which I know I've mentioned a lot, this is my AI operating system. So, it's connected to every tool that I actually use and it has information about my entire business. It knows my business better than I know it honestly because it has a better memory. But the idea is I got here because I've connected all my tools and because I use this for everything and every new memory, every new skill, every new project gets indexed into my wiki here, which I will have sections on exactly how you do this later in the course, but just bear with me here. The point I'm trying to make is that's my AI operating system with my second brain inside. And if you guys want to get the full course, which I would recommend you do after this course, that will be my free school community right here. The link is in the description. Like I said, completely free. So the point I'm trying to make is this idea of connecting your tools is a core piece of building your AI operating system. Context, connections, capabilities, and cadence. And so what I'm talking about right now is kind of like the context and connections thing. So this is where I like to start. I think of my tier one connections which are revenue, customers, calendar, coms, tasks, meetings, and knowledge. So, right now, you know, you've created your folder in Claude, which is going to evolve into your AI operating system. But you're thinking to yourself, maybe okay, Gmail, um, you know, Slack, what else do I connect? I don't know what else to connect. The answer is go look at the tabs you have open right now. Go look at your bookmarks. Go look at your history. What tools are you visiting frequently? what tools do you need to go to pull data or to talk to people? That's what you want to connect. So, it'll be things like where is your revenue living? Can you connect your bank accounts? Can you connect um any reporting tools? Can you connect Stripe? Can you connect your, you know, school? Where do your customers live? You probably want to also have some customer data in there. You probably want to have your calendar in there. You want to have communications, so Google Workspace, but also for me it's ClickUp and Slack. I have tasks in there. So, ClickUp and Notion. I've got my meeting recordings. my transcripts get pulled in automatically from Fireflies and then just other knowledge. So, I've got a ton of stuff locally. I've got a ton of stuff in my Google Drive and of course on my YouTube channel. So, that's obviously not all of it. I think every single week you're going to discover, oh shoot, I need to connect this. And then when you do, it's as simple as googling that tool and then you Google API documentation. So, let's say you use Fireflies and you want to be able to connect Fireflies to cloud code. You would just go Fireflies API documentation. Okay, cool. Fireflies has an API. I will go ahead and say, "Hey, Cloud Code, you know, take this link, figure out how to use this." And then I'm going to go get my API keys from Fireflies. And once I get that, I'm going to chuck that in the ENV. And boom. Congratulations. You just connected another tool to your AI operating system to your cloud code. That's all it takes. The hardest part, honestly, is just like identifying what tools you need. And the best way to do this is to actually test it. Like prove to yourself that you [snorts] can do this. And what I mean by that is you have to make the habit switch. So what it looks like right now is you've probably got all these different tools and I'm not going to um like label all these, but let's just say you've got all these different tools and you open up your Chrome or whatever browser you use and all day you're just switching between a bunch of different tools and you're copying and pasting things. What you need to do is just transition to the fact that I can just use Cloud Code and just talk to Claude Code and that's it. because Claude can be the one to go use all these tools. So, all I have to do as a human, you know, let me just draw a nice little picture of Oops, that's not what I wanted. As myself sitting here on, you know, my computer just talking all day. Then all I have to do, that's supposed to be a computer by the way. All I have to do as the human is just talk to Claude. And now this thing is like my assistant. It does everything for me. And I try to challenge myself. One of the metrics I challenge myself to is what percentage of my day, what percentage of my work can I do from this window right here? And I know that might sound weird. It might sound like, oh, I'm going to be less productive. But no, trust me, not only will you be more productive, but you're going to start to build more skills. You're going to make your cloudmd better. You're going to improve your entire system. And that's how you end up with something like this with hundreds of skills, millions of context files and projects, and something that feels like a co-founder. It's really a great feeling to be to have. So, you're going to go through these tiers. You're going to list out the tools that you want to connect and then just go through find if they have an API, find if they have an MCP, maybe they have a CLI, and start to get connected. What I want to show you guys right now, because I'm hoping a lot of you guys are on the Google Workspace ecosystem, is how you can connect to the Google Workspace CLI because that allows you to talk to everything in the Google Workspace environment. Mail, calendar, sheets, docs, slides, all of it. So, that's what I'm about to show you guys how to set up. Just a quick warning before this next video starts playing. Some of the clips that I'm inserting into this course were recorded a few months back, meaning they might be shown in VS Code extension or the terminal instead of the Cloud Desktop app that we've been using so far. I just wanted to give you guys a warning. Functionally, exact same. So, don't worry about it too much. It just might look a little bit differently, but all you have to do is listen to what I'm saying and follow along with what I'm actually doing and you will be just fine. All of this stuff is still relevant. Otherwise, I wouldn't be putting it in this course. So, hopefully that makes sense. See you guys in the video. 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 100 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 endpoints 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. So, here you can see it said, "Got 30 unready 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 the 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. And there is one more important thing I need you guys to understand about connecting your tools. So what you might have noticed is that in cloud code on the desktop app, if you go to customize, you can see some skills in here, but then you can go to connectors. And what are connectors? They're basically a really simple way for you to connect to different tools. If I click on browse, you can see we've got Reend, Tableau, Canva, Figma, Gmail, notion. And this is really easy because you basically just connect and then it prompts you to sign in. You know, like you kind of ooth in. Oh, that one's already installed. So, if I did Notion, for example, it would just bring me to Notion and it would want me to sign in here and then my Claude Code desktop app would automatically be synced up to notion and I could just interact with it. And it's very easy because you don't really deal with, you know, potentially the API keys in the same way. As you can see, here's where I would choose which workspace I would request connection to. Now, the reason I wanted to bring this up is because it's easier and a lot of people might just tell you to do that. But here's what I want you to think about. If you rely on these connections, that is not great because what's going to happen is if you switch off to a different desktop app or a different harness, you lose everything. So by going through the method that we've talked about where you open up your files and you go to yourv and you put your API keys in there and you build connections through that that means later if you want to switch to codeex which is chatgbt's coding agent or if you want to switch to Hermes agent or openclaw or any other new tool that comes out then you'd have to reconnect every single thing which is a huge pain or even if later you decided you wanted to go from cloud code desktop app to VS code which is something that I I like to use a lot as well you would have to reset all those connections again that is why I'm teaching teaching you guys to do this all a little bit more manually, but it's not too difficult at all, but more manually by setting up yourv um API keys in there because it's just way more transferable. You're you're way more tool agnostic and becoming tool agnostic is the most important thing you can do because these tools evolve so quick. New models, new tools every day, every week. So that is why I want you guys to think about the fact that all we're doing here is we're building a bunch of folders and files. any agent, any AI can sit on top of folders and files and look at them and be just fine and use them. So, that is super important to me and I just wanted to make sure that I communicated that to you guys because I knew some people might be thinking, okay, well, why would we not just use the connectors inside of the desktop app that are so much easier to connect? That's why if you want to go for it, but just think about when you have to switch or if you want to switch later, that's going to be a real pain for you to reconnect potentially like 20 or 30 or 40 tools. All right, awesome. Let's move on to skills, which is my favorite Cloud Code feature ever. Skills exist regardless of really whatever AI model you end up using. So, when you're building these skills, these are also tool agnostic, which is great, but skills are so so important. So, let me find some blank space over here so I can draw out some stuff about skills. We're going to grab this little cloud code crab, place them down here. So, when you're talking to Claude Code, the idea is that when you ask it to do something, it just understands you, right? knows your processes and it knows what to do and specifically if it does a process once good or well then you would hope that if you ask it to do it again next week it would do it just as well if not better. So the idea is that we have a bunch of skills, right? Let's just call Yeah, we'll just say skill. And these are also going to be MD files. So let's say skill.md as we know that that stands for markdown. Think about it like this. These are just recipes. If you wanted to make chocolate chip pancakes, I don't know why I always use this example, but it just makes sense. You would open up a recipe for chocolate chip pancakes. If this was your first time ever doing it, you would follow that recipe because you don't know off the top of your head the measurements. um how long to cook it. You know, you don't know exactly what to do, but what you would do is you'd open up the cookbook or you'd Google on our phone the recipe and then you'd follow it to a tea. You would see step one, step two, step three, step four, and you would just do that. After you finished making, you know, you got the deliverable from that recipe. You would say to yourself, "Okay, did I like this or did I not?" You know, maybe I wanted to add more chocolate chips. So, I'm going to change the recipe and add more chocolate chips. So, then you would change the recipe and then next time you want to make chocolate chips, you'd open this back up. You'd run it again and you'd see if you liked it and eventually you get to a spot where you like the skill or you like the recipe and now whenever anyone asks you, hey, you know, can you make me some chocolate chip pancakes? You know exactly how to do it because you reach for the skill and you just follow the instructions. So that's what our agents do. What ends up happening is we have tons of different skills and when we ask our agent to do something, it is able to think to itself, oh, okay, cool. So, this person wanted me to do a, you know, a morning briefing. And all I have to do now is I have to go grab this morning briefing skill, read it, and then I'm going to go execute, you know, the actual morning briefing on my workspace, you know, so on my laptop. Anyways, so it would read this and then it would execute. And then your job as the human is to say, "Okay, cool. This is pretty good." But once again, here's my feedback. And then you just get into this place where the agent would then loop. it would update the skill and then you run it again and then you judge the output, you loop, you run it again. So take a look at this example. This is my grill me skill. What you'll notice is there's this little front matter which is called YAML front matter. It it's yl front matter. I don't know exactly what the yl stands for but it's front matter. And this is important because this is what the agent reads in order to decide should I use the skill or not. So this skill is called grill me. It says, "Enter the user relentlessly about a plan, design, or topic, checkpointing every answer to a brainstorm file so nothing is lost. Use when the user wants to stress test a plan, get grilled on a design, run a brainstorm or discovery session, extract what's in their head into a doc, or says, "Krill me." I'm going to do a full section later on the skill. It's it's a it's a great skill. But this is what it looks like. So, let's say I say, "Hey, you know, Claude Code, I want to um build out a new course on cloud code for knowledge work." for example, which is actually I did this exact thing when I was planning out this course. I said, can you please grill me about the way I use cloud code, the way I think about it, and what I need to know. And then what it did is it just asked me tons and tons of questions. But before it did that, it had to read the skill and invoke it. And it and the reason I wanted to tell you guys about this front matter is because that is how it decides. Look at this, right? If I go to my Herk 2 project and if I go into mycloud and I go to the skills folder, I have tons of skills. There's like 40ome in here. So, because there's so many skills, what this looks like more like in reality is our agent has to look through so many skills to be able to pick out the right one, which is overwhelming and it starts to cost tokens. So that's why we use this front matter which it's a process called progressive disclosure which basically means the agent is able to quickly scan all of the front matter for every single skill and based on the description decide ah this is the one that I need to use based on the request that the user just requested from me. So that is why it would then pick this one then it could read everything and then it would invoke it. So that's how sort of the skills look. That's how they work. And that is how progressive disclosure works. So let us go ahead and build our own skill. The cool thing about skills is they can be invoked by natural language. Like if I said, "Hey, can you just grill me?" Or, "Hey, can you run like my storm research?" They would be invoked. But you can also invoke them from slash commands. So if I do a slash, you can see that I've got a command called session handoff, which I could invoke by doing slash. Or I could use, you know, slashgrill me, for example, which is the one that you guys just saw. So you can use slash commands. And what else is cool about that is there is a slash command from Enthropic called skill creator. Create new skills, modify and improve, blah blah blah. So I'm going to call on that skill and then I'm just going to in my natural language tell it what I want to build a skill around. Before I do this, there are two different ways that you can actually write skills or make skills. So let me once again come over here and show you guys visually. There are two ways. One of them is you kind of proactively are building skills and the other one is you build a skill after the fact. So what I mean by that is let's say we decide okay I want a skill for my morning brief. So what I'm going to do is I'm going to say hey Claude code help me build a skill to help me with my morning briefings. Here's what you're going to do. Step one is you go to my calendar and you see what's on my my day. Step two is you go to my ClickUp. You see my tasks that are due today. Step three is you read through my conversations and you see if there's anything that I committed to blah blah blah. That is how you build the morning briefing skill. Or what you could do on the other side is you just do that. So instead of planning out and saying, "Hey, help me build the skill," you just do the thing. So you would do step one, you would do step two, you do step three, you do step four. You do all of that manually with Claude. And then you would say, "Hey, look back at all those four steps that we just did. That is a process that I do every morning. So, can you turn that into a skill? So, you basically have those two paths. You can either say, "Hey, help me write a skill." And then explain 1 2 3 4. Here's what we do. Or you actually do the action and then you say, "You know what? That would be a great skill. Turn that into a skill for me." So, let me show you. Um, we're going to proactively build one just to keep this simpler. And also, what I'm going to do is I'm going to clear out this conversation because we don't need all this in here. So, I can do a slash command to clear slashcle. And then we have a fresh chat. So, I'm going to invoke the skill creator skill. And now, let's think of a good use case to build a skill around. Hey Claude, I would like you to help me build a skill. So, I want something that's going to help me sort of just manage my email inbox a little bit better. You should be able to touch my inbox because we set up the Google Workspace CLI. So, that's the first step is see if you can reach it. And then what I want the skill to do is basically give me a rundown of all of my unread emails and then help me sort of just like triage them. Tell me if anything's important. tell me if you know there's anything that I committed to that I need to respond to and if I need to reach out to anyone else on my team basically just help me triage these emails and label them for me high priority you know which ones needs actions which ones can be completely ignored and then after that happens and after you've given me a quick brief we'll actually take action. So I'll say hey you know all of those down there you can just mark them as unread for these three emails I want you to help me create a draft blah blah blah. So you're basically going to help me triage my inbox and clean it up. Okay, so that was a very messy prompt, right? And that's why sometimes it's better to build a skill after you've done something. So, what we're going to do here is it's going to start to build out the skill thing. And then what it's going to do is we're going to run through this example and then we're going to go back and improve the skill. The first step is that it's checking the Google Workspace to see if it can actually hit my inboxes. There we go. Reachable. And there are 201 unread emails. So, I certainly do need the skill. And now what it's doing is it's saying, "Okay, so I have everything set up, but before I write the skill, there's a few questions that I have for you." So, it's asking me some questions to make this skill better. I have 201 unready emails. How much should we triage in one run? I'm just going to say the most recent 25 to 30 just to keep this simple. When the skill labels an email, what actually should happen? Read Gmail labels. Brief only, no labels, stars plus brief. I'm going to go ahead and say brief only, no labels, just so it's not doing anything that I'm not explicitly approving, at least to start. Once we've ran the skill 10, 20, 30 times and we've kind of like battle tested it and we feel more confident in it, then we can maybe make it a little bit more autonomous. But to start, I like to be in full control of everything. What categories should the brief sort emails into? Let's just go on high, action, ignore. That's totally fine for now. And it's going to keep building out this skill. So, while this is finishing running up, let me just talk about some of the common questions I get around skills because skills can be as simple as like a two- sentence prompt, but they can also be pretty complex. So, let me show you guys a quick example. If I go into my skills here, let me show you an example of one that is kind of more on the complex side. Okay, so this is one called packaging, which helps me out with sometimes packaging up YouTube videos and stuff like that and brainstorming. So, it's called packaging. Here's the description of when to use it. And then what you'll notice inside of this skill is we're routing to other files. So, sometimes it needs to read this full packaging playbook, which is a massive um markdown file of packaging rules. So, it says read this every time. It has Nate's actual decision logic. Then it went to the decision logic source. So another massive markdown file. Then it can also read my channel data. And then it can also look at thumbnail analysis. It can also look at a script to generate thumbnails. And it also has to find my API key. So this is an example where we have tons of brand assets like all of my thumbnail assets, the core model. And look how long this is. There's so many different instructions. There's so many different modes. There's so many different decisions to be made. And every time that I use the skill, it gets better and better, right? because, you know, I give it that feedback loop. There's lots of files that it references. Here's one called idea mining. So, we use this when someone asks for content ideas, video ideas, what to make next, or just to run idea mining. So, once again, this actually needs to be updated cuz I have more than this many subscribers now, but context files, you know, execution. But what's cool about this is this skill calls on sub agents. So, I know we haven't talked about sub aents yet, but skills can do so many things. It can reference full workflows. It can reference full scripts. It can reference sub aents. So the first agent that's supposed to run this skill will call on the YouTube analyzer sub agent and then later it will call on my researcher agent. Anyways, the point I'm trying to make is skills can be really simple. It could be a two sentence prompt. Skills can call other skills. Skills can call sub aents. It's basically whatever process you have. It's basically just an SOP. However you decide you want to do something, a skill just packages it up so that you can consistently do that again every time. Another cool thing about skills is because they're just markdown files, you can take skills from other people. You know, they will have open source GitHub repos like this superpowers plugin that has skills in here. And this gives us skills for brainstorming and for other things like that. If I go to the skills, you can see there's a brainstorming one, there's an executing plans, there is a dispatching parallel agents, there's writing plans. So, you can leverage other people's skills and other people's subject matter expertise by taking the markdown file that they give you for a skill. For example, this brainstorming one, like I said, just a markdown file. It's just a simple prompt and then you can put this into your own project and you can use it. So, if you go on X or if you go on LinkedIn, you'll see people talking about these really cool skills and plugins and it's kind of just like an open marketplace where people are sharing stuff. If you guys remember the grill me skill that I've been talking about, I was inspired to create that by Matt PCO who made this skill called grilling. And look how simple it is. This is literally one of those examples I talked about where this is like, you know, five or six sentences and it's just a prompt, but it's still very, very effective. And once again, I could download this, put it into my own project, and then use it. Okay, so the skill is done. Obviously, it's not perfect yet because we haven't even really tested it. But if I go into mycloud and I go to skills, you can see we now have one called inbox triage. And inside of this inbox triage skill, we have some references, we have some scripts, and then we also have the main markdown file. And what I'm assuming is in this main markdown file, it calls on the references right here. Um, yes, inbox triage scripts. So, it calls on the script and then it also calls on this reference which is the cookbook MD which it's still being written out it looks like. But that's the whole point is that inside of the skill, the markdown file is the master instruction. And sometimes you include other assets like in my YouTube thumbnail skill, I have brand assets in here that needs a call on because it needs to use my, you know, my head shot to create some of those thumbnails. So that is what this looks like. You can see that it's being built once again completely by Claude and it already has like the front matter. It already has the description. So you really don't have to worry about the technical details of how do you actually physically build one. You just have to worry once again about speaking clearly about what you want. Okay. So I'm going to blur out all of these emails obviously, but here are some things that it says high priority. And I would agree that those are high priority. We've got some things that need action. Um this one's something I just need to approve. This is something I need to respond to. And this actually this one could be ignored. And so what I'm going to do is say, "Okay, cool. This looks pretty good for a first pass. The only thing I would say here is the third email in the needs action bucket, you can move that to ignore. So if you ever see an email like that again in the future, just make a note that from this particular sender and for this particular reason, those can be ignored because I don't actually need to action those at all." You can see it says that's the skill. Nothing was touched. All 16 are still on red. Now tell me what you do and then after it makes this change I'm going to say cool go mark all of those that are in the can ignore bucket I'm going to say to mark those as unread in Gmail and then maybe you could say like hey so for those couple that were high priority can you create a task for me in ClickUp or can you create a task for me here and then I will remember to do that by the end of today. So when I talk about the idea that we want to make this thing understand your preferences and your workflows and your business so well skills are the core of that skills are the instructions and the preferences that you can save. So right here you can see it added this rule into the skill.mmd. So the skill.mmd got changed. You can see right here it said edited the skill.md and it added 13 lines right there as you can see. Awesome. So for now this skill is complete. What I want you to do and add this to the end of the skills is that once the user has confirmed that all of those emails that are in the can ignore bucket, you can just go ahead and mark those off as unread or sorry, you mark them off as red once the user has confirmed. So go ahead and mark those as red and then update the skill to say that. Awesome. So it has marked those as red. I will check that in a sec. It's also edited the skill. So if I open this up, you can see it added this line right here that said, "How do you clear the ignore bucket?" Once Nate confirms that he's fine with it, you mark them as red, blah, blah, blah. So, that is how we see that it edited the skill. And now, let me check the email real quick. Awesome. So, blurring this out, of course, but you guys can see, well, you probably can't, but the ones that I said to ignore, it went ahead and it marked those off as red. Sweet. So, that is how we built our first skill. Just remember that all of the skills that I use on the dayto-day and on the week to week, they're not done. Every single time I use it, I'm able to give it some sort of feedback. Sometimes you don't, but you always want to look for areas to improve those skills, especially as different models come out. So like Opus 4.7 might behave differently on a skill than Opus 4.8. So every time a model drops, just run your skills and make sure you still like them. If you ever end up switching your harness, so if you switch from Claude Code to something else like OpenClaw or Codeex, they can still use those skills. You just have to make sure they're in the right folder for them to see. You know how this one is called a Claude? So, for example, um, codeex looks for skills in a codex folder, I believe, or maybe it's a agents folder. So, it's just a little bit about learning what's the terminology for this harness. But because the fact that all of them are just markdown files and all pi python scripts and files and folders, they all transfer over. So, that was your first skill. Now, what you'd want to do is you'd probably want to think about, let me think about my week. Let me think about things that I do that happen based on an event trigger. So, maybe every time a new lead processes a form, what do I do? That's a great opportunity for a skill or maybe even an automation. And then maybe everything like every Monday if I do something or every Friday if I do something, what is that process? And let me turn that into a skill. So you're just going to start stacking up your library of skills. All right. So moving on to number 15 here. We're going to talk about context windows, which is so so so important. So let me find my little graphic here for context windows. This is the one we're going to start with. So what is a context window? Remember how if I open up Cloud Code and I click on this little button in the bottom right, we see right here context window and it says 110,000 out of a million, which is about 11% of our context window. I can open this up and see what lives in the context window. So messages are taking up 72,000 tokens. System tools are taking up 18,000 tokens. Skills take up this many. System prompts take up this many. Whatever. If I go ahead and I do a slashcle, that would wipe everything clean. That's how we get a fresh session. Right now, the idea is that we have a million tokens to play with until the model has to automatically like reset because it can't take all that context. It's too much, you know, information. But the thing is, the models reach something called a dumb zone. So basically, answer quality drifts as the context window fills. So at the beginning, you're super super sharp. And if you guys have ever talked to Claude in chat, you don't see the context window. You basically just keep talking. So if you've been having a conversation with chat with Claude chat for a full day or for multiple days and you ever think to yourself, "This is getting really, really dumb." It's because all of that context is being loaded up. So what that does is it causes Claude to get confused, forget things. It just gets dumber and dumber. And that is called the dumb zone. And it's also called context rot. So a big part of your job as a manager is to manage the context rot. Like you know how truck drivers are only allowed to drive a certain amount of time before they have to like pull over and rest? That's because the longer they're awake, the worse their cognitive function becomes, right? Like they their reaction time gets slower, their judgment gets worse. Same thing with models. So your job is to basically when you get to the point where the model is starting to hit that context rot territory, what you need to do is you need to be able to wipe the context clean without getting rid of the knowledge and like losing progress because that's obviously worst case scenario. So right now at the time of filming this video, the models basically have a context window if we're using cloud code of 1 million. So 1 million is the max, right? On this end we have 1 million and on this end we have zero. Now what I like to do is I've typically found that when I get to 250K I like to do a reset. So this isn't drawn to scale, but let's pretend that this green for me is 250,000 about 25% of the full window. And that's when I will reset my context. Now, how do I do that? I built my own custom skill, which I'll give you guys for free. It's very simple, called session handoff. So, I'm going to do session handoff. Go ahead and execute that skill. Now, what that does is it's going to look at everything that we've done and it's going to look at anything that might be open like open decisions, any files that we were editing. Basically, a quick summary of everything that we've done, right? So, you can see we have where it started. We have decisions locked and what shipped. We have key files for the next session running state verification deferred and open questions and pick up here. So then what I do is I copy this message. Remember right now we're at 112,000. And then I do my slash clear. Now our context window is at zero. Then what I do is I paste in that session handoff message. I hit enter. And then the context window is going to fill up a little bit again, but it's going to actually pick up right where we left off. So the whole idea is like let's say you know every single you've got shifts you've got workers that come in and they work on code or they work on projects for five hours at a time when the person is basically closing out their shift they're going to hand over a document to the next engineer and say hey here's what I did here's you know some bugs here's some things to keep in mind here are the files I was working on and then that that new engineer can open up their shift right on the same page so that's basically what the session handoff skill does you can see I'm completely picked up it knows everything because it wouldn't have if I just did a clear. Now look at this. If I open up my context window now, this is at 55,000 tokens. Did this all take 55,000 tokens? No, because system tools by default will take up some. MCP tools will take up some, memory files will take up some, skills will take up some, system prompts will take up some, and then the rest will basically be your messages and other things that you do. But on a blank fresh session, your context window might already be like 30k or 40k because of just what's in your project. And that's a big reason why, remember earlier when I was talking about this whole idea with with uh skills about progressive disclosure because every skill this is basically autoloaded in and that's what your agent can look at. But imagine if every single skill the full markdown file was loaded in. You know sometimes the full skill is you know hundreds and hundreds of lines. So because of the whole progressive disclosure that is why we're able to save a lot of context and only invoke a skill if and when it is needed. So it's all starting to come full circle here. Isn't that pretty magical? Anyways, that is the context window. My best practice is basically if we get past 250,000 300,000, I'm going to do a session handoff and then just paste it into a new chat and keep on working. Cloud code basically has something called autocompact or a /compact feature which is a summarize and keep going. But the autocompact kicks in way too late. It kicks in like way more around like this area where you've already probably gotten stuff worse. And um it also takes a long time. So, the session handoff skill will be in the free school community that you guys can go and grab completely for free. The link for that is down in the description. You're just going to go to the classroom. You'll go to all YouTube resources and then you can grab every single resource that I've ever given away for free. GitHub repos, skills, templates, anything. It's all found in here in my free school community. As you can see, this is also where we have a 7-day challenge as well as a build your own AI operating system course, which is what I want you guys to all take after you finish this course because it's really going to help you level up. But this is what I want you guys to do next. So go ahead and request to join the free school community. We've got almost half a million members in here. It is a great place to be. You can ask questions, collaborate with people, stuff like that. So the context window theory is really important to understand because there's a lot of things that we're going to learn later in this course that help you protect that context window and help you keep this as lean as possible because also all of this contributes to your 5-hour limits and your weekly limits. So managing context and managing tokens is a really important thing to get good at. But right now, I just needed you to understand, you know, clearing and context rot and where you can, you know, get visibility on this stuff. And now we're able to take that knowledge into the rest of this course. All right. So, let's talk about memory. What else can you do to make your agent actually remember things about you in a way where you know you're not repeating things? So, let me go back into cloud. I'm going to go to my Herk 2 project because this is just where I have tons and tons of stuff, right? I am currently making a course right now which actually you're aware of my knowledge work cloud code master class and I'm trying to explain the concept of memory to the audience. So what I want you to do right now is tell me where do you look in my project or globally what files where do you look when you need to find memories about me and things like my preferences and just having a bit of an automemory sort of feature so that we're continuously growing our relationship and you get smarter over time. Where do you actually look? Because I think of memory as a couple different things. Memory in my mind is first of all like the actual chat. So the fact that it remembers what we're talking about in one session. Then we also have the ability for it to remember like preferences, to remember decisions you've made, to remember meetings you've had, that sort of idea. So kind of like building cloud code as your second brain. So you guys remember earlier when I showed you this Obsidian sort of second brain of mine. All of these are not only knowledge, but I would also consider these memories because it has my YouTube transcripts, it has my meeting transcripts, it has decisions I've made, it has my chat threads, it has things that I found important enough to want to store so that Claude could also pull them. Okay, so let's take a look at what it said. It said the automemory folder, and this is something really cool. Cloud has auto memory which basically means after a certain amount of sessions or a certain amount of time cloud will look at what you've done and it will write memory to the auto global scope. So here is in the users in the nates in the docloud in the projects we have memory. It's a folder of 72 individual markdown files one fact per file. Each file has a name like feedback noel hooks.mmd or reference corporate structure.mmd. A file holds one thing, a preference that you've corrected me on, a project state, a reference fact about your setup. The key file in there is called memory.mmd. So remember we have our claw.mmd. We also have a memory.mmd and that is the index. Those are tagged with front matter. So user, feedback, project and reference. Then it also considers the claw.mmd files as memory. So once again, we've got the global one and we've got the project one and we've got the private local one. I don't really touch these too much, but that is a third one you can you can pull. I'm not going to talk about this right now, but that's more so like when you're collaborating with a team, if you want to keep one cloudmd that's just for you and then one that's sort of like this is the general project system prompt. So, you know, those are the two differences. And then the herkbrain wiki, which is basically this thing that I just showed you guys, this is the wiki of everything. None of this is autoloaded. What happens is if it realizes, okay, I don't understand based on my memory, based on the cloudmd, or based on skills, I will look here. I will look here for things like team, finances, metrics, strategies. That is how this one works. But once again, the important mental model cloudmd is the rules. Memory is, you know, learned facts. And the cloudmd, if you guys remember, actually, you know what? I'll just open it up again. What was really important to me is that I treat this cloudmd as a router. Meaning cloud reads through this and it understands if I need this, I go here. If I need this, I go here. If I need this, I go here. If I need this, I go here. And that is how it's able to have this feeling of memory. Now, how do you actually turn on automemory? Is it enabled by default for everyone? How does that work? Because what you'll notice here is in cloud on the desktop app, if I go to do a slashmemory, we don't have slashmemory. We have consolidate memory, but we don't have a just a regular command called slashmemory. But if I go into my cloud code on the VS Code terminal, I'm just switching back to a different model here. We do have a slashmemory. If you see this, I can go slashmemory. And then right here, I can turn automemory on or off. So earlier in this video when I talked about where should you use cloud code for the majority of this video we're using the desktop app just because it's easy to understand and it just has a nice UI. But the one limitation about using it in something like the desktop app is there are a few a few very niche slash commands that you don't get for the majority of your driving. 99% of the time you don't need these commands but sometimes you know there's just little tiny things where the terminal version has more functionality than the others. So, it's good to get familiar with the terminal every once in a while, but like I said, for the most part, you are okay. And you can also see right here that it is on by default because once again, Claude itself has skills to read its own documentation. So, if you ever have a question about how Claude works under the hood or trying to figure out something about your setup, just ask Claude to to figure it out, to help you research it. Another big mindset shift here is treating this thing like a mentor, not just like a an engineer, not just like your your best friend. It is the smartest person you know and it is your mentor. So you can ask it questions. You can ask it why'd you do that? What would happen if you didn't do that? What was that tool call you did? Why did you need to do that tool call? All these sorts of questions. Being genuinely curious is what helps you get way more out of this thing. So anyways, automemory should be turned on by default for you guys. But if you want to drill in, you can find the actual memory files because they're just markdown files and you can go look at them. So remember this is the path that it told me to go to to see this. So, I'm just going to copy this, open up an explorer, paste that in, and in here we have the 72 markdown files that it was referring to. So, like feedback LinkedIn balance line, um, feedback team names from wiki. So, I just opened one up real quick. This is a feedback internal doc visual style. It's got description, it's got metadata, and then it stores a memory, which is basically this is what Nate told us, why, how to apply, blah blah blah. So, this is super super cool. All right, so let's talk about AI slop. AI slop means different things to different people. Some people think AI slop means AI generated images that look bad or those Tik Toks you might see where there's like two AI generated fruits and there's like a love story between them. Whatever you consider AI slop, let's talk about it real quick because how I define it is basically when I can clearly tell something was generated by AI. Now, I don't necessarily think that's a bad thing because people should be using AI, but I do think you get to a point where you start to lose trust in people. And the most important thing is that you are judging all of your work and you want people to look at it and be like, you know, I don't care if he used AI or not, but I trust that he checked this and I trust that because he signed his name to this, he is taking accountability and responsibility for it. So, I actually wrote up a little post which I'm going to read for you guys word for word. The real problem with AI slop. So, I'm sure you guys have heard the term AI slop and everyone sort of defines it differently. Maybe you think of those Tik Toks, blah blah blah. I use that example again. But I want to talk about it in the context of communication, internal, external, content you put out in the world. I write my LinkedIn post with AI. My agent knows my business, how I write, how I speak. That's just how I work now. And there's nothing wrong with that because I think that everyone should be using AI to write if it makes them more efficient. But this isn't a binary yes or no. It's a spectrum. Sometimes AI can draft and send automatically. Most of the time I want it to just draft and then I review. If someone sends me an email with M dashes everywhere, I don't actually care at all that they used AI. But the fact that I can clearly tell it's AI generated isn't the problem. What I do start asking is, did they even proofread this? Is this even accurate? And subconsciously, I might start losing trust, not in the email, but in the person who sent it. Our job here has changed from writer to reviewer. And this quote really stuck with me. You can outsource your thinking, but you can never outsource your understanding. When your name is attached to the content, you take credit if it lands, as you should, but that also means you need to take accountability if it's incorrect. Taste and reviewing is becoming more important than ever. And maybe that should be R. So, you can tell I didn't write this with AI. AI is super intelligent and powerful, but I don't want to see a world where we trust AI so much that we stop reviewing things and then the human on the other end of the content starts losing trust in us. That's why even though I write with AI and people know that, I still try my best to disguise it and make it sound as innate as possible. And like that's exactly why I wanted to show you guys this AI phrase kill list, which I kind of showed earlier. But you should be building up something like this and you should be building up the way that you speak. So I've obviously got skills for helping me write LinkedIn posts or YouTube scripts or um emails, internal communication. And I want my communication to sound like me. And I want people to trust that what I'm doing is me. Because it's not just about communication. It's also about if you send over a report or if you send over some analytics or if you send over, you know, you're writing up a case study or the copy that's on your website. You don't want any of that to clearly be AI generated because once again, trust is like the biggest currency and you don't want to lose that currency. And not only for you, but it's important to communicate this down to your team when you guys are all as an organization learning how to use AI better. So anyways, just a really quick section. I hope that that hit and I hope that that little change of pace real quick was helpful to you guys and just kind of made you think about the way that you really truly want to be using your AI agents and how the teams should be using them together. And looking back at these mindset shifts again, you'll notice that number three, you can outsource your thinking but you cannot outsource your understanding is one that I referenced in that post as well because I think that one is just a really really good one of how the future is going. You know, like we're able to outsource the ability for agents to go do the research and to grab a bunch of sources and give you some sort of consensus, but you still have to read that. You still have to understand it and you still have to know how to apply it. Okay. Now, this next section of the actual kind of agenda up here is about picking what to build because that's a huge pain point that I hear from my audience when they're, you know, hey, I'm just getting started. I don't know what projects to do. Like, where do I start? So, let's look at just these mindset shifts real quick on the method. the method about how to decide five mindset shifts real quick that I'm just going to read off the constraint is the only place where work compounds everywhere else you're just busy automate a broken process and you don't fix it you scale it becoming AI native doesn't mean using AI for everything it means being a problem solver who sometimes uses AI you can't automate what you can't map every build needs a north star one number picked before you build that tells you whether the build was worth it and if these mindset shifts are interesting to you guys then you should definitely Check out the book. It's called Becoming AI Native. But anyways, what do these mean to me? The first one, the constraint is the only place where work compounds. We see too often people, whether you're working with a client or whether you're trying to automate your own business or whether you're trying to help yourself out, automating things that aren't actually being used very often. They're automating things that sound sexy, right? Like, oh, we need this sales agent to do all this. And they start to try to automate that or we need, you know, this fancy thing that I saw a demo of on LinkedIn. But really what you need to think about and the way that I always like to think whether I'm thinking about my processes and my team's processes or whether I'm consulting with a business owner. The way I think is let's take the flow of your business right like let's imagine it as a pipe which is you know I think a great analogy. So let me just draw a pipe real quick. This is your pipe and ideally what happens is you have water coming in the front and the water flows through and this is your business. When water comes out the other side, this is you basically this is your profit because things might happen in the middle and you know you have to pay people, you have to do whatever, you lose clients, they turn out this over here, all of this is profit and you want to maximize on both ends really how much water comes in and what percentage of that comes out. Now what we want to be thinking about are in this process where are the clogs, where are the constraints that sit here that basically make less water go through? And there's not just going to be one. You know, you're going to have multiple constraints and they're going to be different sizes and different priorities. But the point I'm trying to make here is I like to work from front back. I like to work with the first constraint. So I say tomorrow if you got 5x the amount of customers going through your pipe, so 5x the amount of water, what would break first? And that forces the business owner to walk through in their mind what do they do on the day-to-day? What does the team do? Where is water being stopped? And how can we, you know, basically that's the problem. That's the only way you grow a business is if you are attacking these constraints. So by attacking the constraint that is going to not only make the automation more powerful and and more successful for you, but it gives you a clear road map of where to start. And then guess what? Once this bottleneck has been unclogged, once the clog has been unclogged, now all the water is moving to the next constraint. And even though some more's, you know, sliding through right here, you're still having a big clog. And you want to get rid of that. And then after you get rid of these two, for example, guess what happens? Because there's more demand up front. another clog pops up. So this is a never- ending cycle, but that gives you at least a framework to work from. So that's why the constraint is the only place where work compounds because if you have, let's say, this main big clog up front and you've got a bunch of little ones in the back, oops, then does it make sense to start eliminating these? I don't know. I mean, you could argue that yes, so that when you open this one, water flows through. But really, this is just like you want to go for the constraints first. It's a theory of constraints. And then I just wanted to loop this back to number nine, which is every build needs a north star. So when you're deciding on a problem that you want to attack, before you build it, you want to think about what is the metric that you're looking at and which way do you want to move it. So let's say right here we realize that the clog is actually like up up front, right? Like there's just not much business coming in the front of the funnel at all. So we basically just have no water in the system and that's the problem. Okay. Well, let's say the metric here that we want to fix is um we are getting about five leads a week. So, we would think about this. Five leads a week is our metric and our north star is we want to design a system so that we can now be bringing in 15 leads a week. And that's how we're able to from the beginning everyone is aligned on this metric. If we're able to hit this metric in the next couple weeks or months, does everyone consider this product a success? If the answer is yes, then it's a great thing to work on. But the problem that we've seen from when I've done consulting, when I've built stuff, is that if we don't align on the metric, a lot of people are confused about, okay, well, how do we know if we got ROI on this? You know, like what where's the benefit? I can't actually see it. Because productivity isn't as onetoone as for something like running ads, you know, like you pay an agency to run ads, they are going to spend $200,000 a month and you can directly see that those $200,000 brought in an extra million to the business. But when you're removing constraints and when you're doing things on the back end, you don't always see it super clearly about how it affects the bottom line. So every project that you work on before you start building it, before you agree to it, pick the north star and make sure everyone agrees, okay, this would affect the bottom line in some way and it would be a success if we could move the metric from five to 15 leads coming in a week. So at a large scale to really impact the business, that is typically what I think about. I think about constraints and I just stick to that. Now, when you're just getting started, so like you're sitting there today and you want to this week start to automate some stuff. Maybe you don't yet have first of all like the confidence in that or like the luxury to be able to make those decisions or the budget for it. Right? So, what I want you to do then is start to write things down. Literally get out a piece of paper and I want you to write down kind of the following information. I want you to think about from week to week and like doing an audit of yourself. So, like what processes do you have or you know what tools am I using? What processes did I repeat? What are my triggers? And by triggers, I mean what things happen throughout the week that basically trigger you to do something else. A lead comes in, what do you have to do about it? A customer support ticket gets submitted, what do you have to do about it? And I think this one is powerful because this will help you identify like five to 10 processes. And then once you have those five to 10 processes that are pretty event- based or trigger based, you then think, okay, in my typical week or month, which one of these happens the most often? And then you just want to probably go for that one. Unless that thing is like super super high risk to the business where you have to be involved right now and you can't really change the way you're doing it, then maybe you want to bump down. But then you just basically have that whole list and you drill down on those. And then this other mindset shift that I called out here was that you can't automate what you can't map. So remember how we talked about the way that you actually build these skills or you build these automations is you have to basically define how they work and whether that means you do it first and then you actually execute or whether that means you execute and then you build a skill around it. If you don't clearly understand the process already then how in the world do you expect an intern to to understand it or an AI agent to understand it? You have to know the process well enough or you have to be able to talk to the stakeholders or the subject matter experts that do in order to automate it because the subject matter expertise that goes into the system is the most important thing. We talked about this, right? No matter how good the AI model is, you could have the best AI model in the world and the best harness in the world, but it's not going to be able to do anything meaningful with your business and your business data unless you feed in that theme, that subject matter expertise. You guys have probably heard some of these phrases like garbage in garbage out. That's that's a really popular one. or like context is king. And these are two pillars that I believe will be true forever. Even though with new tools coming out, this these two things super super important. And then there's one more that I like to reference which is Abraham Lincoln. If I had 6 hours to chop down a tree, I would spend the first four sharpening the axe. Meaning there's so much importance in the planning stage, mapping things out clearly, writing down processes clearly before you try to actually automate them and you know build them or execute on them. So the picking what to build is just a very mindset oriented thing. And the actual building itself is once again very mindset. It's it's all about the planning. It's all about the clear communication and it's all about sitting there watching the agent go steering it to make sure it's going in the right direction and then giving feedback and iterating and iterating and iterating. And we've talked about all of this stuff where you guys could now pretty confidently go do that. We talked about prompting. We've talked about understanding how to connect your tools. We talked about skills. And we've talked about context windows. And there's going to be more later on about managing this right here, token management. But you guys have basically all the skills that you now need to start to pick processes and go automate them. And all of the stuff that we're about to dive into is just getting a little bit more advanced and taking it really to the next level. So that is how you pick what to build. All right. So we've mentioned sub agents a few times. When we talked about the skills, I talked a little bit about how sometimes you can have skills call on certain sub aents and you can also have sub agents call on certain skills. And sub aents are really important because you know how we talk about the context window. What happens is when we use a sub agent we can delegate tokens to be spent in a different context window in a fresh sub agent. That way our main orchestration agent right here is able to just call on a bunch of them. So, it's pretty cool because instead of having one main session where we just fill up the context window, we can have our main session keep it clean because it's delegating work to little smaller sub aents that are each having their own context windows and we're able to just disperse it out a little bit more. The other cool thing is let's say this main agent is on Opus, so it's the most expensive. This main agent can delegate work to all of these little workers that are all like maybe on sonnet or maybe even on haiku. So you can delegate work that's a little bit less like high priority or high risk to cheaper models and you can just get some really cool results by doing stuff like that. So I'm going to go ahead and shoot you guys into a video that I made pretty much breaking down everything there is to know about Claude Code sub aents. Just a quick warning before this next video starts playing. Some of the clips that I'm inserting into this course were recorded a few months back. meaning they might be shown in VS Code extension or the terminal instead of the cloud desktop app that we've been using so far. I just wanted to give you guys a warning. Functionally, exact same. So, don't worry about it too much. It just might look a little bit differently, but all you have to do is listen to what I'm saying and follow along with what I'm actually doing and you will be just fine. All of this stuff is still relevant. Otherwise, I wouldn't be putting it in this course. So, hopefully that makes sense. See you guys in the video. So, I don't know what's going on up here, but I just told Cloud Code to spin up five different sub aents, and they all have different personalities. One is going to be a complete beginner, one will be a software engineer, one will be a business owner, one will be a publisher. And it comes back, and it says, "Okay, I'm kicking off all five now, each with a distinct persona and lens. These will run in parallel." You can see that this is now running four agents. The fifth one's about to spin up. And on the bottom, if I click into a different session, so we've got the main or we've got like the beginner, and I enter this conversation, we can actually see what's going on here. Meaning if I scroll up I can see the actual prompt that the main session kicked off to this sub aent. So here we have Linda 58 years old a retired elementary school teacher. You are a complete beginner to AI and then we see the actual task which is to read all the chapters and give a bit of a review. And so all of the other sub aents probably have a very similar prompt if I go to like the enterprise exec. So same exact prompt except for here you're role playinging as David 52 a COO at a 12,000 person Fortune 500 financial services company. So anyways, the point being what we can do is have our main session up here and the main session can delegate to as many different sub agents as we want and all the sub agents can have different chat models, different personas, different skills, different subject matter expertise. And if you watch my video where I ranked all of my favorite Cloud Code features, sub agents ranked number six. So today, what I'm going to do is I'm going to tell you guys exactly how to use them, what they are, when you need to use them, and how you can use them better than 99% of people using Cloud Code. So let's not waste any time and get straight into today's video. Okay, so what is a sub agent? You guys just saw a demo. We have a main chat. So, right here is where I said, "Hey, can you spin up five different sub aents?" And what it did is it right here kicked off five different ones. And then it comes back with an overall review. Apparently, I need to do some work on this book because I only got about an eight. More info on my book will be coming soon. But anyways, the main session is basically the orchestrator. It says, "Okay, cool. So, I am the one who's actually talking to Nate, but what I can do is I can spin up a bunch of sub agents that can only talk to me, and I can assign them work. Go read these files. Go do this research. Go fix that bug." and then you come back to me with a report of what you did and I'll communicate that back to Nate. So there are a ton of different reasons why these sub aents are useful and why they exist. So let's just start with this first one which is that it keeps your context clean. So let's say I'm in cloud code, right? And I'm just talking. Hello, how are you doing? What's going on? Let's build something, right? Like maybe we're doing research, maybe we're building an app, whatever it is. You start to fill up your context window, which you guys can see right here with my status line. You can see right now we're about 48,000 tokens in 5% of the way up. And so as this starts to fill up, it starts to get polluted with information. But if you kick something off to a sub agent, as you guys saw earlier, it's a completely fresh chat. So just to show you guys another real quick visual demo, I'm in the desktop app, which is a little bit, you know, easier to see and it's visually more pleasing than the terminal sometimes, but let's say I said, "Hey Cloud Code, go ahead and kick off a sub agent to do some research for me about a product called Fireflies.ai." And so this is my main session. You know, I can talk to this thing. It'll help me do research on different tools. And then what happens is it kicks off a researcher agent to do the research. And what's cool is right now you'll notice I'm using Opus, right, which is obviously the most expensive model, but we can have a sub agent kick off and do research with Haiku or Sonnet. So we're getting this research for cheaper and we're getting a fresh context. So if I click on this agent here, you can see this is basically the prompt that the main agent sent over to this sub agent which was, hey, research Fireflyy's dead AI. Give us what it is, core features, how it works, pricing, give us all this stuff. And now this agent is the one over here searching the web and creating its opinions rather than our main session. So this helps preserve your main context in case you're ever doing a ton of research or reading a ton of stuff that you don't want to fill up your main context window, right? So that's one thing. There's also built-in sub agents which is the one we just saw, right? That was like basically a built-in cloud code research agent that will you've probably seen it get invoked automatically without you even asking it to be invoked. And then you've got custom sub agents that you're actually able to build yourself. And if you guys remember earlier in the demo when we spun up those different agents, I said, "Hey, one should be a software engineer, one should be a beginner, blah blah blah." You remember those all said general purpose. So those were still builtin native generic agents that just had a prompt. So that doesn't mean that we built those custom agents. That was just a general purpose agent that cloud code prompted differently. If we wanted to actually build a custom agent, that would be a markdown file. So if I open up my VS Code, you guys know in the cloud folder, we have different things. And the one you probably know the best is called skills. So in the skills folder, let's just take a look at real quick my agent builder skill. What this is is it's a markdown file. This lives as markdown so that I could send it to you guys. I could put it in my community. I could send it to my team. And all someone has to do is put this markdown file in there. Claude in a skills folder and then they're able to use it. And so a sub agent is the exact same actual tangible thing as a skill.md file. It's just called something else. You know, we've got the YAML front matter up here. And then we have the instructions of what the skill does and the actual steps to take. So if I open up my agents folder also in my do.claude. You can see I've got a different a couple different agents here. Right. So this one let's just look at is called the clickup-archer.md. And that's an agent that's called clickup searcher. We've got the yaml front matter up here name clickup searcher. We've got the description. We've got the model which I've defined here. We've got the color which means if I actually use the clickup searcher agent it shows the color. So actually let me just show you. can you go ahead and use the ClickUp searcher agent to show me what we've talked about today in the weekly commitments channel? And so what you'll notice is I invoked that with completely natural language. I'll have the ClickUp searcher agent pull today's messages and then right here I can see the green color. So that's all it means when you actually assign an agent a color. It's just so you can actually see it right there. And down here, you know, earlier right here is where it said general purpose. What it says now is ClickUp Searcher. And that's how we know that that's a custom agent that we built ourselves. So anyways, those are the two differences. And like I said, it's just one markdown file. And what this is called up here, the YAML front matter, that's called progressive disclosure. Which basically means if you say, "Hey, go do X, Y, and Z for me," Cloud Code will naturally go search through your sub agents and your skills to see if you have any sub aents or skills to use. And so for the rest of this video, I'm just going to say sub agents, not skills, but they both work with this kind of progressive disclosure um process. But the idea is that cloud code is able to read just the front matter, just the name and the description and then decide does this apply to this prompt. If so, I'll pull in the sub agent and I'll run all of the extra stuff and read it. But otherwise, I'm not going to waste my tokens by reading everything if I'm not going to end up invoking that sub agent. So that's why we have this YAML front matter and that's why that's very important besides the fact that it also defines things like tools, model, and then there's tons of other levers you can pull there, but not going to dive into that right now. So anyways, settings up top and then your instructions go below that. And these are the four that I think matter the most. The name obviously so you can reference the sub aent. The description is really important. This is basically the trigger and this is how you can make sure that your sub aents are getting invoked without you actually saying, "Hey, go invoke this X Y and Z sub aent." So the more precise that your descriptions are, the more often cloud code will actually trigger them and you won't get misfires. Misfire is basically meaning you want it to invoke a sub agent but it doesn't or you don't want it to invoke a sub agent but it does. And so sometimes the only way that you can really make sure that you're you're tuning the actual front matter so that you're not getting this misfires is you just have to test it out and you just have to use it more and more and then like when it doesn't fire and you think it should you just think about okay why didn't that happen and then you update the description and then same thing if it's the opposite way around. And then if you go to the actual cloud code documentation on these sub aents, you can see all of the different things that you can actually put in the front matter. You can put tools like we just mentioned, but you can also put disallowed tools. So if you don't want it to ever write or edit files, you can put that so that these sub aents are explicitly read only. You can also define things like which MCP servers it's allowed to use. And you can even give it skills. So basically any setting that you want to configure for your custom sub aents, you can pretty much do. just come to the documentation, have cloud code read the documentation and say, "Hey, I want to set up a sub agent that does X, Y, and Z. It should not be able to do X, Y, and Z. It should be able to look at this data, not look at this data." And it will help you build the right YAML front matter. So, how do you actually write a great sub agent? So, obviously not having a weak description. So, having, you know, a very precise type of description. You can even say something like use proactively if you want it to fire off, you know, pretty generously. And then after you have the actual front matter dialed in, it's all about the body. The body is the way that the sub aent actually works, what skills it invokes, because yes, sub agents can invoke skills and skills can invoke sub agents. So, keep that in mind. They work together. They're not um you know, competitors. And you have to have that same idea once again that that you have to iterate. It's not going to be perfect on the first try. Every time you use your sub agent, you have the opportunity to give it feedback on what it didn't do well and how to make that better and then what it did really well and how to make sure that it does it every time. And real quick, what's the difference between a skill and a sub aent? Well, honestly, at their core, they're very similar because you're able to define, do X, Y, and Z in this order. You know, here's a prompt, here's a persona, whatever. But the main difference really is that one has a clean context window, and one doesn't. And you can run a ton of different sub agents in parallel in, you know, independent sessions, as we saw earlier, whereas the skill is typically more of something that I'm kind of triggering in my main session all the time. But once again, that doesn't mean that I don't have a great LinkedIn research skill that I hand off to sub agents to use. You know what I mean? So really I think of it as kind of like the parallel use and the clean context window and of course the ability to use a different model. Now there is something that I'm going to show you guys real quick in cloud code which is like it allows you to build agents very easily with a slash command. You can also do it with natural language but um I'll show you that in a sec. Before we show you that I did want to kind of go over this real quick which is project level versus global level sub aents. And this is the same, you know, if you understand how the cloud code like settings files work or the cloud code like hooks and skills, MCP servers even, it's all the same. You always have project level stuff or you have global level stuff. So project level stuff is basically what lives in your project in that repo. So right here we're in my Herk 2 project and anything that you see inside of mycloud right here is project level. So all of these agents are product project level. All of these skills are project level. And then I've got other sub aents and other skills that are global. So, for example, if I say, hey, where does my session handoff skill live? That's going to find that globally because if I go to my skills, there's no skill in here called session handoff, as you guys can see. But right here, the session handoff skill lives in your global skills directory at the, you know, the user level. And so, global ones are usable by every product on your machine. So, no matter which project or repo I'm working in, I can always use that session handoff skill or I can always use that, you know, sub agent that I've built and it belongs to me. So, if I share this GitHub repo to someone, they won't get that skill or they won't get that sub agent. It's not a big deal because you can easily say, "Oh, you know, you accidentally made that sub agent globally, but I actually wanted in this project, can you just move it?" And because it's just a markdown file, they move super easily. Or you can even have them both. You know, you can have them in both spots. But the reason why I wanted to explain that before I showed you this is because if you know, you have to choose. So, if you do a slash agents, you can look at what agents are currently running. If you've got a bunch of sub aents, you can go to your library and you can see a bunch of different built-in agents down here like claude, claude code guide, explore plan, and then you can also look at your project level agents. So, for example, we could look at, you know, the AI trend hunter. We can look at carousel planner. You'll notice that some of these have different models like all of these are sonnet, but then some of these have different project memory. You know, this one has project memory. This one has none. But anyways, what I wanted to show you guys if you go to create a new agent, you choose here if it's a personal or global or if it's a project. So let's just make a new project one right now. In order to create it, we can generate with claude or we can do manual configuration. So I would probably come in here and choose generate with claude. And then you basically just describe what this agent should do and when it should be used. And it says to be comprehensive for the best results. Create me a sub agent that criticizes all of my work. I basically want to be able to hand it off ideas and I want it to not agree with me, but I want it to um criticize it. I want it to roast it. I want it to play devil's advocate and look for every possible hole in the plan and what could go wrong and give me back basically that report. I want this thing to be invoked whenever I say roast my plan or review my plan. Anything like that. So that's my prompt. Obviously that's pretty concise. So like if you really had a good sub aent use case, you'd probably want to give it some more detail and some more nuance there. But I just want to show you how it's able to generate this file from the description. And because I chose project level, it's going to create that in the agents folder within my do.cloud. So in a sec here, we'll see an agent pop up. It'll probably be called like um devil's advocate.md or roast agent.mmd, something like that. Oh, but before that, it also says what tools do we want it to be able to use? So like for example, in this one, maybe I only want it to go with readonly tools. So I could say just readon. And then you know, we could look at some advanced options too, which would be all these MCP servers and a bunch of other things. and even like individual tools. Whoops. Even individual tools like bash, cron create, cronde delete. Like you can get really granular here. But in this case, I'm just going to go ahead and hit continue with readonly tools. And then we're able to choose the model. And in this case, we're going to go with haiku. But you can also inherit from the parent. So if the parents running on haiku, all sub aents that all of that sub aent will be inherited. Or same thing with opus or sonnet. And then finally, we can choose our background color. I'm just going to go ahead and choose pink. And then we get to choose the memory. So whether that's project, none, user, or local. And so really for the sub agents that I'd be creating and the ones that I would recommend you guys do, I'd probably just say project scope. Unless you want all these sub agents to be completely completely innocent, wake up completely blind, no memory at all, then you would choose none. But as far as between project user and local, I'm probably just going to always choose project. All right, there we go. So I'm going to go ahead and save this new agent. And you can see it just popped up right here. It's called the plan roster. And what happens when you create them with Claude is it makes this huge because it doesn't yet understand what you might say and how you want it to trigger. So my first recommendation would be trim this down a little bit because once again this is part of the progressive disclosure. So there's no need for the description to be so long. So I'm literally going to delete all of this. I mean it's good to look at but I'm gonna delete all of this up to here. And really in my case this is good enough, right? Use this agent when Nate wants an adversarial critique of an idea, plan, strategy, blah blah blah. Trigger on phrases like roast my plan or review my plan. We've got the tools, the model, the color, the memory, and the name. So now I'm just going to open up a new session of Claude. And um let's real quick just say so I've got this plan and I want to create an ice cream stand in, you know, uh Chicago. I want to create this ice cream stand on Oak Street Beach and I don't yet have a refrigerator and I want to sell the ice cream all day long for about, you know, 20 bucks a pop and it's just a little a little piece of ice cream. So, um, go ahead and roast my plan. This is actually interesting. So, I created a skill called roast and it's going to use that instead. So, it defaults to that because it thinks that it's good enough. And in the skill, the roast skill, I actually have it spinning up five different sub agents. So, that's a good demo. I didn't mean for this to happen. These are all general purpose sub aents that live within my row skill, but I'm going to go ahead and cancel that. I'm going to run this prompt again, but this time I'm going to explicitly tell it to not use a skill, but like I said, that's a good example of showing you that in a skill, you can have it fire off a bunch of sub aents. Anyways, the whole reason why the roasting thing is so top of mind is because cloud code and AI in general can be a little bit of a sickopant. It can just be a yes man. So, having things worked out like a roast skill or like a plan roaster sub agent is pretty helpful. Okay, so look what happened here. It did not invoke our roast, our plan roster sub aent. So what I'm going to say is go ahead and take a look within ourclaw agents folder. We've got a sub aent called plan roster.mmd and you didn't invoke it here and I'm not sure exactly why. Go ahead and read the description of that and and look back at my prompt and help me understand why did you not fire off the sub agent so we can make this better because that exact prompt is something where I'd want you to use that that sub agent. And so that's really the way that I think about um iterating on my descriptions both for skills and for sub agents. Just just understanding like why didn't it fire or why did it fire and how do we then rework the description. I do think there's a little bit of you know foul play here because my roast skill got invoked earlier and it's probably like defaulting to those skills before a sub agent. So, you know, maybe that wasn't the best example, but I guess it's good that it happened so I can show you guys the way that you might think about improving your YAML front matter. Okay, so completely my fault. I didn't close out the front matter. So, good tip. You have to close off the quotes if you open them up, right? That can break your JSON. It can break other things as well. So, it will break your YAML front matter. It said the problem wasn't judgment, it was mechanical. It also said, "Hey, you know, you do have a rose skill, so maybe there was a little bit of, you know, cloudiness there." So, I completely get that, but it went ahead and it updated the description. You can see it made it a little bit longer, but there's still collision between the roast skill and the plan roster, right? They both get invoked kind of similarly. So, really, the best thing to do here is you would combine the skill to say, "Hey, whenever you run the skill, you also invoke the plan roster agent instead." But for the sake of the demo, I am just going to actually be way more specific about what to use. So, there goes our prompt once again. The copy and pasting out of the terminal is horrible. So, usually if I want to copy and paste something from the terminal, I will tell it to write it to a text file or I will just use it in the desktop app. But either way, I was way more explicit here. You can see I said use the plan roster sub agent, not the roast skill. And now it's initializing our pink plan roster sub aent. And what I can do is I can go down to this section down here. I can open up this other terminal and we can see the exact prompt that got sent over to our plan roster, which was roast this business plan hard. Here it is in full. I want to create an ice cream stand in Chicago, blah blah blah. So, it's basically exactly what I said. Tear it apart, hit every flaw, the missing refrigerator, the absurd $20 price, and then the sub agent already finished up. So, it sent us back to the main session. And now the main terminal is going to interpret what the plan roster sub agent said and then give us the rundown. And what you'll notice here is the the plan roster took 22.8K tokens, but those 22.8K tokens did not pollute our main session. All we got was basically this much, which is pretty awesome. So anyways, that's a real quick a little bit of a sloppy example, but hopefully it showed you guys the different elements to play with and you know the way that you think about using these sub aents, but that's what it looks like in cloud code. The way that I like to think about these is the same way that I've thought about AI since the beginning of my YouTube channel, which is your AI. You know, it's very fun and cool to have one mega personal assistant agent that can do everything, but really the best way to do it is to have each AI be a specialist. And that's where your main general ones can be pretty good at, you know, a jack of all trades because of skills, right? You invoke a skill and now it's good at LinkedIn post. Now it's good at doing research. Now it's good at scripting videos, whatever. But really, the sub agents are actual specialists. They have subject matter expertise. So you can have one that's a security auditor, you can have one that does tests, you can have one that writes docs, you can have one that's an expert with databasing, whether that's the architecture or the queries or anything like that. And you can just silo basically this assembly line or parallel work of a bunch of agents that are good at one thing and really really good at that one thing. And the other thing that's cool about that is you can borrow subject matter expertise from other people. This is just one of the hundreds of thousands of examples out there, but there's a GitHub repo which I'll link in the description. And this one's called awesome cloud code sub aents. So if you scroll down here, you can see there's a bunch of sub aents that you can use and in different categories, right? You've got an API designer, a back-end developer, a GraphQL architect. We've got other language specialists like TypeScript or SQL. You know, you can scroll through and find a lot of these custom same way that you look for skills from other people, custom sub aents that other people have already built, and they maybe know a lot more about CLI developing than you do. So, they've put all their subject matter expertise into a sub agent, and now you can just use that because all it is is a markdown file. Now, yes, because everything's open source and because all these markdown files are out there, you want to be careful, right? Like, if you're downloading a file or you're putting into your system, just make sure there's no prompt injections in there. Make sure there's nothing, you know, malicious. And you can even do it by having maybe a sub agent that verifies open source repos. And it's read only. It can never send data. It can never do anything. And all it does is verifies that there's nothing malicious inside of that markdown file. So anyways, we looked a little bit about how cloud picks out the agents. It can be automatic and it can automatically invoke things when you are like looking through your codebase or whether you are doing research. It'll automatically chuck some out there. You can also have them very proactively use sub aents if you have things like that in the description so it fires frequently. You [snorts] can also list them explicitly by name. You know, you can tag the agent name or you can say, "Hey, use the plan roster sub agent like I just did in that example. And you can also launch a session as a sub agent. If you do claude with a flag of the sub agents name, it'll actually put you right in a terminal right away with one of those sub aents." And honestly, I never do this, but it's nice to know that that feature exists. So, once again, just wanted to hit on the point that you can do readonly sub agents, which is pretty cool, just by using tool restrictions and giving them only certain things. It's always nice to have basically the mindset of if my AI could touch data or could read data, I have to assume that it will. Even if I never prompt it, I have to assume that it will. And that's the difference between a permission layer being explicit tools that it's allowed to use and explicit MCP servers it's allowed to use and just prompting and saying, "Hey, don't do that or you don't need to read that. Don't worry about it." There's a big difference between those types of permission layers. And then, of course, you have the ability to save a ton of money here. Let's say you have to read a 300page research report and just get, you know, maybe three fun facts from it or just get a summary. There's probably no reason unless it's a really really, you know, technical report to use opus for that. Probably not even sonnet. So delegate that to a haiku sub agent to read everything and then send back just a small summary to your main session. And that's how you have the system where you have your smart boss, which is the opus model that you talk to on the day-to-day that just works with a bunch of little haiku agents. It's going to save you a lot of money. it's going to keep things moving faster and that's the way that you want to start utilizing these things. Another way that you can also keep them from getting out of control is you can have a max turns set on these sub agents. So maybe they're starting to do loops of research or they're doing loops of reviewing through a codebase. You can say, "Hey, max turns equals 10." Honestly, I don't use this very often because most of my sub aent delegation is research or very specific workflows where it doesn't really I'm not worried about a loop and I'm keeping my hands on either way. But that is once again just another nice lever to pull. So then after we've seen all these benefits, hopefully it's starting to become a little bit more clear, but a lot of people might also still wonder, okay, so when do you actually use a sub agent? When is it really better to? So one core question you can think about is, is this about to dump a pile of stuff into my chat that I'll never read again? If that's ever yes, delegate it to a sub agent. If it's no, then maybe you keep it in line. But there's also some other things to think about, too, right? So let's look at some signals. If you're about to read a lot of files, do some sub aents. If you're going to spit out a wall of output, maybe do sub agents. If it's a job that you keep repeating, build a custom sub aent for it. If it is independent stuff and you can run a ton of things in parallel, like you know, maybe you have 15 chapters of a book and you want each chapter to be reviewed and like it doesn't have to be in chronological order. All of them can be reviewed at the same time. Then that that's parallel and then you can go ahead and do those independent jobs. And also if you want like an unbiased reviewer because once again sub agents can wake up no context completely fresh no memory and you can get an honest review. Now you don't need a sub agent if you're just doing a quick edit if the steps depend on each other right so if it's like 1 2 3 then four if the agents need to talk to each other then that's when you would need more of like an agent team or a different type of orchestration. I've made a video on agent teams before. Um they are more expensive than sub agents because they're they're talking and stuff like that but they share task list and everything. Sub aents do not work that way. It's just a onetoone relationship between sub agent and main session, not like a one to many. If you've got five sub agents running, they cannot talk to each other. You would also skip them if you need the sub aent to have like the context of the entire conversation or if it needs to ask you a question because you don't really get to talk to the sub agents. You know, the main agent is the orchestrator. Now, there's also something to think about which is a fairly newer feature. It was with with the release of Opus 4.8, which is the dynamic workflows. And what that does is it spins up a workflow that typically delegates to a ton of different sub agents in parallel. So remember the idea is that the main chat is the orchestrator and you've got a bunch of different sub aents running whether that's three or whether that's 40. A lot of times if you're asking for a big project and it decides to use a dynamic workflow, then all that's doing is it's creating a bunch of sub aents and it's delegating to them all at one time. So I made a video about those. I will tag that right up here if you want to check out the dynamic workflows video. You'll see an example I did where it spun up 41 sub agents at the same time and just ran them. I've also done some examples, not on video, but like when I was testing it out, where I did some workflows and one of them spun up like 210 sub agents at the same time, which was great, but it ate through my context or sorry, it ate through my session limit like crazy. So, you definitely want to be careful when you're spinning up dynamic workflows. They actually then a few days after this came out, they said, "Hey, we changed the trigger word for dynamic workflows from workflow to to ultra code." You can still say to use a workflow for this, but when you're clearly referring to something else, Claude won't kick off a dynamic workflow. So, you want to make sure that you are being very careful about when you kick off those dynamic workflows because like I said, they are expensive. So, anyways, that is pretty much all of the stuff that I wanted to talk about here with sub agents. So, the whole thing on one slide, just to do a quick recap, if it's just one quick thing, you don't need a sub agent, right? Just because this feature is awesome, which it really is a great feature, that doesn't mean to force it. because sometimes if you're forcing too many sub agents, you're going to get worse results. So, play around with them, understand the benefits, and start to kick them off when you really do need them. If you want to share them with your team, keep them in your project, keep them in your repo. If you want to keep sub agents just for you that you can use across any project, then put them in your home folder. Kind of, you know, make them globally or personally. You can save a lot of money by having cheap workers with one smart lead. You can get better results by letting a fresh agent review your work or do work in parallel. If you want to do a giant parallel job, go ahead and check out a dynamic workflow. Just be careful of your session limit. And if you're not sure, if it's a pile of stuff that you're never going to reread, then go ahead and spin off a sub agent. Whether you are using cloud code in the terminal or whether you're using in the desktop app or even the VS Code extension in VS Code or, you know, on the web, wherever you're using cloud code, everywhere that you use cloud code can run sub aents. And the principles that I just talked about are always the same. This is where they live. That's how you invoke them. They're always YAML front matter. And those are pretty much the best practices. So, I know we covered a ton of information. If you guys want to download this exact slide deck, all you have to do is join my free school community. The link for that is down in the description. Once you join here, all you have to do is click on the classroom, click on all YouTube resources, and then you'll be able to find everything that I've dropped in here for free. GitHub repos, skills, templates, slide decks, whatever you want. It's all in there for free. All right, so we got sub agents crossed off the list. We're just going to keep making our way down through the rest of this course. So, next we have websites. And websites kind of go handinhand with GitHub because Cloud Code's really really good at building websites for us. It can build websites out of any coding language that you want. So HTML or you know CSS or all the other ones out there. It's really good at that because websites are code. But what happens is when we build code, it might give us something like a local host, which if you've never heard that before, don't worry. It's it's we'll break it down. But it's basically a URL that only you locally could open. If you tried to copy a local host URL and give it to your friend, nothing would pull up on their laptop if they tried to open that up. I've seen some funny tweets where it's like, "Hey, I'm a beginner. I just started using Claude Code. Check out what I built." And then they, you know, they attach a local host URL. And obviously that's like a meme. It's a joke, but it is pretty funny. So, just keep that in mind. We're building the website in code and then the code we push that to GitHub so that we can actually deploy that somewhere on the cloud. So, that is what I'm about to walk you guys through in this next video. Just a quick warning before this next video starts playing. Some of the clips that I'm inserting into this course were recorded a few months back, meaning they might be shown in VS Code extension or the terminal instead of the Cloud Desktop app that we've been using so far. I just wanted to give you guys a warning. Functionally, exact same. So, don't worry about it too much. It just might look a little bit differently, but all you have to do is listen to what I'm saying and follow along with what I'm actually doing and you will be just fine. All of this stuff is still relevant. Otherwise, I wouldn't be putting it in this course. So, hopefully that makes sense. See you guys in the video. 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 Claude 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 anthropic 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 claw. 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 cloud 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.mmd 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 claude code, and right here you will see the web designcloud.md 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 asterisk 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.MD file, but then it will think, okay, the user asks 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 vibe coded. 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 Claude 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 Cloud 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.mmd 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 Amazon 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 cloudmd 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 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. Ooh, that's super nice. We've also got some scrolling tech companies. So, we've got Editen, 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 cloudMD 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 claw.md and say, "Hey, Claude 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 [snorts] 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, [snorts] 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 the 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 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 Claude 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 Claude 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 it 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.dev. 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 mention, 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 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 Versell 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 auto deploy between Verscell and GitHub. And Verscell 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 Herk AI and now it's going to create the.get 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.md 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 cloud. Mmd 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. Awesome. So now that you guys understand how building the websites work and how cloud code is able to push to GitHub and push to versel to actually deploy them, you can continue going down some other like design stuff if you want. And if you do, you should try out claude's tool called claw design. So it's literally just a different web-based app that is basically specifically only designed for design. So if you want to check that out, I did drop a full course on cloud design which I will tag right up here. But anyways, now that we have finished talking about websites and GitHub, we are going to move on to talking about trusting the output. This is a really important topic and it's pretty nuanced because the the trust factor differs based on the type of automation that you're actually building. So, let me explain what I mean by that. So, deterministic versus non-deterministic. Deterministic means essentially predictable input and then we know what's going to happen and we know what we're going to get out. So, think a vending machine. we know that we have, you know, A1, E4. We can click these buttons and when we click the button, we know exactly what's going to happen and exactly what we're going to get. Now, nondeterministic is basically just the exact output. We don't exactly know what the trigger is going to look like. We don't exactly know what's going to happen inside the process, and we don't exactly know what we're going to get on the other side. We obviously have things that we're steering the system towards and we're trying to get one type of output. But because AI is essentially a black box and it's kind of like a slot machine, AI automations are more non-deterministic and they're designed to be. That's good about them. You know, they're flexible and that's what unlocks so much extra opportunities in this world is that now we have intelligence inside these automations. But with that non-determinism comes a lot of other things to think about. Think about a quick example of like responding to emails or writing cold emails. With the deterministic side, what we would do is we would have variables. So variables would fit into some sort of templated email copy and the variables would say, okay, the person's name goes here, their company name goes there and their, you know, MR goes there or something like that and it was very static. But now on the nondeterministic side, the AI can just look at all this input and then write a more personalized email. So it's not a template anymore. It's more of an actual, you know, generative AI. It's generated content. Now, from there though, I think about this as an AI systems pyramid. On the bottom, we have chat bots and at the top we have agents. So, let me explain kind of what I mean by this and why I like to think about it like this. So, really the core message that I think about and that Enthropic talks about and that other, you know, tech labs and leaders in the space talk about is you want to design the simplest solution for the job. Which means if the process doesn't need AI, there's no reason you should put AI in there because as you move up this pyramid, which is basically, you know, you're moving up in, let me actually change the arrow type. You're basically scaling up in autonomy as you move up, which also means you're scaling up in basically like unpredictability. And as you're scaling up these two things, you're also scaling up a few other things like cost and risk, just to name a few. So as you move up, you have things to think about as well. So, a chatbot, what do I mean by this? I think about a chatbot as basically something where a human has to trigger it. So, we're in full control of when we want the chatbot to run. I even would think of this as things like your claw skills that we're building, right? Because typically what's happening is you are invoking the skills by yourself, which means you're able to sit there, watch it, you're still kind of driving, you're still in control, you take the output, and now you're doing something with it. That's not really a high-risk environment because it's not like it's going to shoot off thousands of requests and do a thousand things without you asking unless you know that's what the skill entails on the inside. But think about this more like something where you actually trigger it as the human. And then what we have are workflows. These are deterministic workflows that are nothing new. It's basically just automation. Maybe like moving data from one spreadsheet to a database or something like that that takes no AI at all, but it's triggered by an event or on a schedule. So this thing runs while you sleep and you're not really there. It's not as much human in the loop. So it really starts to scale up here, but still not super dangerous because this is still like basically 100% deterministic. You know the input and you know the output. Then you get up to AI workflows where basically the order of events is still the same. It still goes 1 2 3 4 5 and then somewhere in that process there's an AI step. So let me try to make this a little more practical with an example. Let's take first of all let's just do the customer support example. responding to emails. So with a chatbot or something like that, what happens is an email comes in and then the human would trigger the skill. So the email comes in, the human triggers the skill, the skill looks up the database, it you know generates the email and then the human would go off and send the email back to the person. So that is very like you know we are in control the whole way. Now what happens with a workflow? Okay, so the email would come in that would maybe trigger a like data lookup tool and that could be a lookup based on the email account and then maybe that could just trigger a notification for a human to be able to actually go look at the ticket and process the email. So that is like a workflow because it's basically just moving data from one side to the other from left to right and there's no AI. Now let's take a look at what an AI workflow here could look like. Let's say an email comes in. We then do a data lookup so we can collect more information about the user. But then what happens is instead of notifying a human, what we want to do here with the AI is maybe we generate an email. And then this is where the non-determinism kicks in because we don't know what the email is going to look like. But over here, this is still like one 1 2 3. It's still like a workflow in nature because we know the steps that are going to happen and in what order. But then when we get to an agent, it's much different because what happens with an agent is we don't know what's going to happen. We would basically have an AI agent that has a bunch of different tools. And obviously I'm just making up what these tools would be, but we don't know if the email is going to come in and then the agent will go, "Okay, I'm going to use none of these tools." Or maybe I'm going to use the data tool twice and then the ticket tool. Or maybe I'm going to use the ticket tool, then the data tool, then the ticket tool again. Because that loop of reasoning and decision is all inside of this AI step right here. And that is where we lose the element of a workflow. We don't know the steps, but we do know that this is like the fully, [snorts] you know, most autonomous situation that we could possibly have. And we know that on the end result, what we want is for the agent to respond to the user with an accurate email. But that's why we have to be able to build the right systems to make sure that we actually trust that output. So hopefully that paints a little bit of a picture about the different ways you can orchestrate these systems and what you're kind of sacrificing or what you have to be aware of as you move up this pyramid of the AI systems. And all of this stuff will come into play later when we start to talk more about like routines and deploying automations and things like that. Just keep in mind you want to build the simplest solution possible for what you're trying to do. And there's one more thing I wanted to talk about here when it comes to actually trusting the outputs. And that's what a permission layer looks like because we've got prompts and then we've got like an actual permission layer like a tool level permission layer. So I should maybe move this up here and then just say here like tool layer. So anyways, let's say this is a visualization of like an agent we're building and we've prompted it to do things like never send an email only draft or never delete our database or never delete emails. Well, the prompt layer is one kind of guardrail, but it's not solid enough. The agent could follow instructions 100 times, but on the 101st time, maybe it forgets to or maybe it just gets a little bit clouded or confused and it ignores that prompt. So the point I'm trying to make here is let's say you said, "Hey, don't ever send an email." A lot of times the email boundary will stay within the prompt layer, but every once in a while it'll sneak out of the prompt layer because it has a tool to do so. So if you take away the tool to send an email, then there's no way that the agent could actually get through the tool layer to hit that email tool. So that's the idea. If you want the agent to draft emails but not send, then don't put a send email tool inside of its tool layer. Keep that on the outside. But then it's perfectly fine to have the draft email tool right here and say you can draft emails, but just don't ever send them. Similarly with delete functions, right? Like why would you ever allow this to be inside of the tool permission layer, even if your prompt says never ever ever ever delete anything, then just move the delete tool out of there so that it physically couldn't, even if it tried to, if it wanted to go rogue, I don't know, whatever the situation is. Don't give it tools if it shouldn't be able to use those tools. And I know that sounds obvious, but it happens way more often than you'd think. You've seen maybe stories on X or LinkedIn where massive companies had databases deleted because an agent went rogue or we actually internally had a situation where an agent sent out like 100,000 emails or 150,000 emails to our list with a discount code and we didn't want it to do that. But what we found is that because it had access to the tool even though it was never told to send that email, it just did. So you have to assume that if an agent can read or touch or use something, assume that it will assume worst case scenario. Let me show you guys another quick example that I think will really resonate because when I first started building AI agents for people or AI automations, this was like the most common request was like an inbox triaging responding agent. So like an an email agent really. So a lot of people wanted one that looked like this and I built a lot that looked like this. We would basically have the trigger being a Slack message. The agent would have, you know, a little bit of a memory as well as a system prompt. And the system prompt would be massive. It would be a bunch of rules about what do you do with the emails, how do you label them, how do you respond, how do you do this, what is important, what's not important, and then after you respond to the to the actual email, you would send a message to the user and say, "Hey, here's what I did. There's the draft or I sent this or whatever." So, you'd have a agent would have a bunch of different tools, a bunch of email tools like draft an email, label, mark them as read, mark them as unread, um, pull them back, like actually get them and be able to read them and search through old ones. And there was probably more. But the point I'm trying to make here is I built a lot of agents like this and they weren't super reliable because of the fact that there was they were agents and there was so much reasoning. There were so many decisions. There were so many logic rules baked into the prompt. And as we know, a prompt isn't exactly a hard layer. Prompting is almost just more like a suggestion. So I then started to design all of my inbox agents like this. Now, this looks a little bit scarier, but it's so much simpler because all of this is a workflow. So, I moved this down from an AI agent at the top of the pyramid to AI workflows where now it is so so simple because what happens is the trigger would come in and then we're just using routing rules. Like for example, right here, if the contact is in um Google contacts, if yes, then we will do nothing. And if no, then we will extract the information using AI. So we'll pull in their name, their email, phone number, information about them, and we have to use AI for that. And then we would create a new record in the Google contacts. Now, every single one of these nodes is just one step. And the workflow is always going to follow the chain. So after we would basically figure out are they a contact or not. Then we would look to see how we respond to the email. We had three routing rules here. If the email equal@client.com, then we would label it over here as internal. If the email domain was bill.approvals@client.com, then we would label as bill or sorry, we would label it as billing. We would then summarize the email and then we'd send a summary to the right person in Slack that hey, we just got this new billing inquiry. And if it was a VIP email, then we would basically just label it as VIP. And so this is a very very simple example of different routing rules. What what you'll notice is that because the decisions are basically being made by legitimately objective facts rather than an AI prompt, this type of system had basically no failures. The only failures would be if it extracted information wrong or if it summarized an email weird, right? Because all of these blue steps are objective. They were simple logic. They were easy. The green where you have decisions and where you have generative AI is where you get the variability. They could perform the exact same these two systems. Like essentially they're doing the same thing in theory. This one on the right was so much more consistent. It was also cheaper and it was just faster because over here you have so many decisions and you have different things going on and you get the visibility is worse. And it's harder to improve this because it's harder to drill down where did something go wrong. Whereas over here if something goes wrong we just follow the trail and we see exactly what happened. So hopefully that makes sense. So here's a message that I actually sent to my team um about a month ago or so. Let me just read this out and then I'll break it down real quick. So the above weekly stats update was not meant to go here. This was like a public channel in our ClickUp. That was an automation of mine that I completely forgot existed. Back at the end of March, I set up an automation to keep the stats on my website current. So every week it pulls my YouTube subscriber count and school member numbers and it updates the website. And I built this on a separate account as a cloud routine. And it was mostly because I wanted to test it and then I made a YouTube video about it, but I completely forgot that that automation existed. It's been running quietly every week for 2 months and I completely forgot it existed, right? It works, which was the whole point of the test, but I never really vetted it. If we think back to my teaching a kid to ride a bike analogy, which I'll explain in just a sec. I basically put the kid on a bike with a helmet and training wheels and then I just walked back inside and took a nap. I told the automation to send me a personal DM each week, but prompting is not a permission layer. And the first five weeks it was sending me a DM in ClickUp, but then it started to go rogue and it started to send other people DMs and it started to drop these weekly stats updates in like general public channels rather than a private DM. Once again, just because I said, "Hey, only send it here," doesn't mean it's going to because it has access to every single channel in ClickUp. Sometimes it might make a mistake. So anyways, no harm done. Nothing sensitive happened. But it made me realize how bad that could have been. the fact that I completely forgot that an automation existed and the fact that I didn't have hard tool layer walls inside of this automation and was just relying on a prompt that could get bad really quick, especially because it was silently doing things that I forgot about. So anyways, hopefully there's some lessons there that you can take out of this. But what is the bike analogy? So basically the bike analogy is the idea that when you are building an automation, it's very much like you're teaching a kid to ride a bike. You can't expect to just put a kid on a bike and that they're going to be able to go 25 miles an hour down the road without falling ever. What you have to assume is that they're going to fall. So, when you put them on the bike, they've got training wheels, they've got helmets, they've got elbow pads and knee pads, and you're still going to hold the bike. You're going to push them. You're going to make sure that they are feeling comfortable. You're going to see, okay, you're leaning too much to the left, maybe shift more of your body weight to the middle. You're going to help them adjust. And slowly, you get to a place where you feel more confident. And if we relate this back to skills, you run the skill, you watch it, you very closely watch it, you give feedback, you run the skill again, you watch it, and you do that and slowly you're able to remove yourself more and more from that process. But what happens is even when the skill is like pretty battle tested, do you want to still just like say, "Hey, go off, kid. Take off your helmet. Go bike down the busy road and I'm going to go inside and take a nap." You're probably still going to like watch them a little bit. And you're going to wait till you feel comfortable to the point where there's basically nothing that could go wrong in this automation because you did all of the things that we talked about because you have the right system in place. That's the right amount of autonomy because you understand the difference between deterministic and nondeterministic because you set up the right prompting layers and tool layering so that you actually feel comfortable with the permissions that this thing has access to. And so like the majority of the work that we've been talking about in this course so far pretty much all lives down here. Like everything that we've been building are systems for a second brain and skills and capabilities so that we can have our agents help us do things much quicker and those are pretty much all things that are being triggered by us. And later when we start to talk a little bit more about deploying things and using cloud routines and stuff like that, that's where you really need to start thinking about these other elements. You know, like if you have a cloud skill that does something like let's just say um when a new lead comes in, you research the lead and then you shoot a message to the team in ClickUp. that probably doesn't need to be a human triggered thing. That's probably where an AI workflow actually comes into play a little bit better and you deploy that after you've evaluated it and you feel comfortable in it. So that is what I wanted to talk about here when it comes to trusting the outputs and obviously there's a lot to drill into once you really start to get into the weeds of building out like pretty big automations then eval comes into play. Evals are basically the idea of having a golden data set. So maybe 100 or a few hundred examples of input and expected output and then running those inputs on your system and seeing how many times did it pass, how many times did it fail, when it failed, why did it fail, and iterating on that automation, changing the prompt, changing the tools, watching for edge cases, and evaluating your systems or QA, quality assuring your systems before you ever push them into production or before you ever roll out a different model or a different prompt or whatever it is. Evals are very important. So hopefully now you're starting to understand some of these things that go into how you actually trust the output of these AI systems. And what you guys are probably starting to pick up on, which I think is important for me to call out here, is that so much of this stuff is non-technical. So much of this stuff is mindset and theoretical like oriented. And that is really really important to realize because as you start to doubt yourself or doubt your automations or have any sorts of doubt or discomfort, just use your words to figure it out. When I first started building automations in Cloud Code and I wanted to test them to see if they would actually work and see if they'd survive edge cases, I would literally say, "Hey, so you know how we just pushed this automation to Modal, which is something I'll talk about later, but we basically built an automation and we put it on a deployment site called Modal." I said, "Okay, so now that that's live, I'm a little bit confused and concerned about what could go wrong. So, help me figure out what are all the edge cases that we might want to think about here and how do we make sure that if something goes wrong, it's not like a bad failure. It's a safe failure." And so, this thing basically helped me look at all of the scenarios and then it designed tests for me. So, me and Claude with natural language went back and forth and we tested all these different scenarios. We tested invoices that came in weird. We tested what would happen if the API was down. We tested a bunch of these things and then because of those tests I said, "Okay, cool. Let's bake in all those guardrails so that if anything errors, I get a notification or the automation gets shut down or we always are doing things in a safe fashion so that the database won't get deleted so that records won't get merged so that nothing ever goes out externally so that we can fail safely and that we have logs of what's actually going on in our systems. Okay, so let's continue talking about how do we keep building out our AIOS here and giving it more memories, more subject matter expertise, more context about what we do. And that is kind of the element of building out our second brain. Just a quick warning before this next video starts playing. Some of the clips that I'm inserting into this course were recorded a few months back, meaning they might be shown in VS Code extension or the terminal instead of the cloud desktop app that we've been using so far. I just wanted to give you guys a warning. Functionally, exact same. So, don't worry about it too much. It just might look a little bit differently, but all you have to do is listen to what I'm saying and follow along with what I'm actually doing and you will be just fine. All of this stuff is still relevant. Otherwise, I wouldn't be putting it in this course. So, hopefully that makes sense. See you guys in the video. What you're looking at right here is 36 of my most recent YouTube videos organized into an actual knowledge system that makes sense. And in today's video, I'm going to show you how you can set this up in 5 minutes. It's super super easy. You can see here how we have these different nodes and different patterns emerging. And as we zoom in, we can see what each of these little dots represents. So, for example, this is one of my videos, $10,000 aentic workflows. We can see it's got some tags. It's got the video link. It's got the raw file. And it gives an explanation of what this video is about and what the takeaways are. And the coolest part is I can follow the back links to get where I want. There's a backlink for the WAT framework. There's a backlink for Claude Code. There's a backlink for all these different tools I mentioned like Perplexity, Visual Studio Code, Nano Banana, Nen. It also has techniques like the WT framework or bypass permissions mode or human review checkpoint. So as this continues to fill up, we can start to see patterns and relationships between every tool or every skill or every MCP server that I might have talked about in a YouTube video and I can just query it in a really efficient way now that we have this actual system set up. And the crazy part is I said, "Hey Cloud Code, go grab the transcripts from my recent videos and organize everything." I literally didn't have to do any manual relationship building here. It just figured it all out on its own. And then right here I have a much smaller one, but this is more of my personal brain. So this is stuff going on in my personal life. This is stuff going on with, you know, Upai or my YouTube channel or my different businesses and my employees and our quarter 2 initiatives and things like that. This is more of my own second brain. So I've got one second brain here and then I've got one basically YouTube knowledge system. And I could combine these or I could keep them separate and I can just keep building more knowledge systems and plug them all into other AI agents that I need to have this context. It's just super cool. So, Andre Carpathy just released this little post about LLM knowledge bases and explaining what he's been doing with them and in just a matter of few days, it got a ton of traction on X. So, let's do a quick breakdown and then I'm going to show you guys how you can get this set up in basically 5 minutes. It's way more simple than you may think. Something I've been finding very useful recently is using LLM to build personal knowledge bases for various topics of research interest. So, there's different stages. The first part is data ingest. He puts in basically source documents. So he basically takes a PDF and puts it into cloud code and then cloud code does the rest. He uses Obsidian as the IDE. So this is nothing really too gamechanging. Obsidian just lets you visually see your markdown files. But for example, this Obsidian project right here with all this YouTube transcript stuff that actually lives right here. This is the exact same thing. Here are the raw YouTube transcripts. And here's that wiki that I showed you guys with the different um folders for what Cloud Code did with my YouTube transcripts. And then there's a Q&A phase where you basically can ask questions about YouTube or about the research and it can look through the entire wiki in a much more efficient way and it can give you answers that are super intelligent. He said here, I thought that I had to reach for fancy rag, but the LLM has been pretty good about automaintaining index files and brief summaries of all documents and it reads all the important related data fairly easily at this small scale. So right now he's doing about 100 articles and about half a million words. So there's a few other things that we'll cover later, but the TLDDR is you give raw data to cloud code. It compares it, it organizes it, and then it puts it into the right spots with relationships, and then you can query it about anything. And it can help you identify where there's gaps in that node or in that, you know, relationship, and it can go do research and fill in the gaps. All right. So why is this a big deal? Because normal AI chats are ephemeral, meaning the knowledge disappears after the conversation. But this method, using Carpathy's LLM wiki, makes knowledge compound like interest in a bank. People on X are calling it a game changer because it finally makes AI feel like a tireless colleague who actually remembers everything and it stays organized. It's also super simple. It will take you five minutes to set up. I'll show you guys. You don't need a fancy vector database embeddings or complex infrastructure. It's literally just a folder with markdown files. That's it. You literally just have a vault up top. So, in this example, it's called my wiki. You've got a raw folder where you put all of the stuff. And then you've got a wiki folder, which is what the LLM takes from your raw and puts it into the wiki. So in here you have all the wiki pages which it will create but then you also have an index and you have a log. So for example in my YouTube transcripts vault here is the index. You can see that I have all these different tools which I could obviously click on and it would take me right to that page or after that I have all the different techniques agent teams sub agents permission modes the WAT framework and then we've got different concepts MCP servers rag vibe coding we've got all these different sources which are you know the YouTube videos and then when I have people or when I have comparisons they will be put in here in the index and then we also have a log which is the operation history so in this case in the YouTube project the log isn't huge cuz I only ran one huge batch of the initial 36 YouTube videos, but now every time I have one, I say, "Hey, can you go ahead and ingest the new YouTube video into the wiki and then we'll see every single time we update this." And then, of course, you need your claw.md to explain how the project works and how to search through things and how to, you know, update things. It's also a big deal from a cost perspective, token efficiency, and long-term value. One ex user turned 383 scattered files and over 100 meeting transcripts into a compact wiki and dropped token usage by 95% when querying with Claude. And obviously token management and efficiency is a huge conversation right now and will always be. The other thing that's really cool about this is there's not really like a GitHub repo you go copy or there's not a complicated setup. You literally just say hey cloud code read this idea from Andre Karpathy and implement it. And people on X are now talking about like this is how 2026 AI agentic software and products will be made. You just give it a highle idea and it goes and builds it out. And Karpathy even said hey you know I left this prompt vague so that you guys can customize it and I'll show you the ways in my two different vaults right now that it changed things a little bit based on the context and understanding of what the project is actually for. Okay. So this was the original tweet I just showed you guys and then he followed up and said, "Hey, this one went viral. So here is the idea in a gist format." So if you open this up, this is basically just another explanation of the core idea of how this works and why the architecture indexing all this kind of stuff. And by the way, this is the part where he says, "Hey, this is left vague so that you can hack it and customize it to your own project." So we're going to come right back to this in a sec, but the first prerec that we're going to do, it's not necessary, but I like to have a nice little front end to see the relationships, is we're going to go to Obsidian and download it. So, if you just go to obsidian.mmd, you can see this is the completely free tool and you're going to go ahead and download it. So, just for your operating system, download this and then open up the wizard and open up the app. So, when you open up the app, it'll look like this. And what we're going to do here is we're going to create a new vault. So, down here, you can see I have Herk Brain and I have YouTube transcripts. I'll just make it a little bigger. I'm going to go to manage vaults. I'm going to create a new one. And now, we just have to give this a name. So, I'm just going to call this one demo vault. and you're going to choose a location where you want to put this. So, I'm just throwing this on my desktop and I'm going to go ahead and create this vault. Then, what you're going to do is go to wherever you like to run cloud code. So, in this case, I'm doing it in VS Code. And I open up that folder. So, demo vault. We get an Obsidian and then we get a welcome.md. So, I'm going to open up Claude. So, I'm going to do it in my terminal. I'm going to run Claude. And lately, I've been liking using my terminal better for Claude. I like to do it inside of VS Code, but the reason is just because I like to see the status line and I have, you know, a little bit more functionality. So, anyways, now that we have Cloud Code open, here's what we're going to do. We're going to go back over to the LLM wiki thing that we got from Andre Carpathy. We're going to copy all of this and we're going to go back into Cloud Code and then just paste it in there. So, that is the prompt from Carpathy that's going to build out everything we need. And then before we send that off, we're dropping this in which you guys can screenshot and then just throw into yours. But I'm saying you are now my LLM wiki agent. Implement this exact idea file as my complete second brain. Guide me step by step. Create the cloudmd schema. Blah blah blah. So this is just telling it what it needs to do with this idea that we just got from Kpapathy. So anyways, on the right we have this cloud code running and on the left we have our Obsidian vault. And you can see it just created those two folders. So it created the raw and it created the wiki as you can see. Now, by default, it threw in four folders. It threw in analysis, concepts, entities, and sources. Once we start to populate stuff, we can talk to it to see if that's actually the way we want to do it or not. Because it's interesting in my personal kind of second brain, the wiki is literally just markdown files. There's no structure to it. And in some cases, that's good. Carpathy actually said, "Sometimes I like to keep it really simple and really flat, which means like no subfolders and not a bunch of over organizing." But then you guys did see in my YouTube transcript one, there were different subfolders. And I think that in this case it actually makes more sense. But you can see that it went ahead and it created a claw.mmd. It created an index and a log and then a few different folders in our wiki. But now it's saying, "Hey, let's go ahead and try it out. Drop in your first source into the raw folder and tell me to ingest it." Okay, so I'm at this website called AI2027. If you guys haven't read this before, it's kind of an interesting read. So go check it out. And now let's say I want to get this into my vault. What I could do is just copy the whole page, right? And it might just come through a little weird. or we can just get an Obsidian extension which lets us basically take articles right from the web and just put it right into our vault. Super easy. So, search for this extension called Obsidian Web Clipper. You would go ahead and add this to Chrome. So, then when you're in the article that you want, you basically just click on your extensions, you open up Obsidian Web Clipper, and then you can just chuck it into your vault. And then right here, you're going to want to set this to RAW because this is the actual folder that it's going to put it in. So you can go ahead and click add to Obsidian. Open Obsidian. And then now you can see in my RAW section, we have this AI 2027 source with the title, the source, and it's not super super populated yet because the LLM in cloud code is going to do that. So here is our file. I'm going to open up Cloud Code and say, awesome. I just threw in an article called AI2027 into the RAW. Can you please go ahead and ingest that? It might ask you some questions. It might also be helpful to before you start ingesting stuff say, "Hey, by the way, this project is specifically for my second brain." So, personal things, business things, whatever. Or this is just a research project. This is where I'm going to chuck you all the articles and all the things that I want to learn about and all the things that I know. So, there's different ways that you can set up the project as you saw with mine. One for YouTube, one for just personal second brain. So, now what it's doing is it's going to read through this article and then it's going to figure out where should I chuck everything into the wiki. It's not just going to create one MD file for this. it might create five or it might create 10. And there's going to be relationships between each of the different sections that it creates. So, it's kind of doing its own method of chunking. Now, one thing I want to call out real quick is with this extension, if you go here and you open up the options for it, you can see that you can actually change where by default the folders are dropped, which is in the location section. By default, it'll be going to a place called clippings, but just go ahead and change that to raw. Okay. So, here it came back with all these questions, right? It said, "Here are my key takeaways from this article, blah blah blah." And now it'll ask you, what do you want to emphasize from this article? What's your focus? How granular do you want to be? What's your plan? So, I'm just going to say, I want this to be extremely thorough. This is my passion looking at where AI is going to go. Um, and this whole project, by the way, that you're setting up in this vault is basically just going to be my place to dump in research about AI. So, help me keep all that organized so that I can query it and that I can, you know, keep my thoughts related. So that's just a quick example of what it might look like for you to give it some more context to continuously build your project. So I'm going to switch over over here to the graph view because I think it'll be interesting to see as it is starting to go through and create those different wiki files. It's going to go ahead and it's going to create all those relationships and we'll be able to watch it in real time. All right, so it's creating all of the wiki pages now and you can see that it said it's going to make about 25 because there's so much stuff going on in the original AI 2027 article. Okay, so our first one just popped in here and there a second one just came through and now you can understand you're starting to see where do you have hubs or where do you just have little individual nodes so this is a major hub someone named Eli someone named Thomas Daniel and you can see all the different relationships here with things like AI governance with things like open brain superhuman coder okay so that ingest took about 10 minutes so sometimes you have to be a little patient with you know it reading through everything and organizing everything but it does a lot of heavy lifting of course when I uploaded the 36 6 YouTube transcripts in batch. It took about 14 minutes. So, it kind of just depends, but it created 23 wiki pages. We have the source. We have six people, five organizations, and one AI systems page. Different concepts, so technical, alignment, and geopolitical. And then an analysis, and then it asks some questions about it so that it can help make the relationships and make the structure even better. Now, let's just open this one up a little bit deeper and see what it actually did in here with this stuff. So we have this is the source with all the main relationships. So as we start to add other articles, we will see other big kind of like nodes and maybe in some cases we'll have relationships between like compute scaling with different articles that we upload as well. So let's just see if I click into the main source we can see the tags that it got. We can see the authors and we can click around. So here's a link to OpenAI. Okay, what's OpenAI? Here's references in AI 2027. Here's some other connections with OpenAI like model spec. Okay, we're in modelsp spec. Let's take a look. We can see other things about model spec and we could also go to how the LLM psychology model works. So this is just super super cool all the relationships that we get and once again all of this stuff that we're looking at was derived from one article and automatically organized and related. So the question now is like what do we do from here? Do we query it inside of this environment? Do we query it from somewhere else? And that's completely up to the way that you want to use this. So, for example, with my YouTube project, I'm probably just going to keep this here and whenever I want to ask questions about YouTube or if I want to turn this into like a website, I can just do that from here. Or if I need to, I can point a different project at this folder since everything's here and it can crawl through the wiki. It can read the index and it knows how this stuff works because you can give it the claw MD so it understands the project as well. So, for example, in this one, which is just my second brain where we have all of the different things about like I drop in my meeting recordings, I drop in, you know, ClickUp channels, summaries, and things like that. This is something that I want to use in my executive assistant. So, what I did in my executive assistant here called Herk 2. If I go to this claw.md, you can see that we have a wiki path. So, whenever you need to read things about me and my business that you don't have already, you would basically go to my Herkbrain vault. You would go to that directory and then you would read through the wiki. You can read the hot cache, which I'll explain in just a sec. You can read the index. You can read the domain subindex. And then you can also just search through everything here. And I said don't read from the wiki unless you actually need it. Here are some things that you might do that you don't need to go read the wiki for. And all of this is my business knowledge. Now, if you guys remember, if you watch my video on setting up an executive assistant, I used to do this with context files inside of this project. And when I changed over to this method, I actually saw a reduction in tokens that I was actually calling in this project. So the thing about the hot cache, right, I didn't actually have this in my YouTube one. So if I go to YouTube, you can see there's no hot cache, but if I go to the herk brain in the wiki, you can see there's a hot.md right here. And this is basically just a cache of like 500 words or 500 characters that it saves, which is like what is the most recent thing that Nate just gave me or that we talked about. In the context of my executive assistant, this is really helpful. You know, it might save me from having to crawl different wiki pages. But in something like the YouTube transcript project, I don't really need a hot cache. So, another thing that I alluded to but didn't really cover was the idea of linting. So, Karpathi says that he runs some LLM health checks over the wiki to find inconsistent data, impute missing data with web searches, find interesting connections for new article candidates, things like that. So, it basically helps you run a lint, you know, every day, every week, whenever you want, which helps make sure that everything is scalable and structured in the right way. And it might even come back and say, "Hey, I don't fully understand this. Can you give me some more info or can you grab some more articles that might help me out here?" So now the final question about this that I wanted to cover is like, "Does this kill semantic search rag?" And the answer is no, but kind of yes. And it all depends on the goal of the project and the goal of the context, how much context you have. So here's a really quick chart that I had my claude code make. I was in my Herk brain where I dumped in a bunch of information about Karpathy's LLM knowledge and I just said, "Hey, can you please explain Karpathy knowledge as simple as possible, keep it super concise, and um compare it to typical semantic search rag." So, it found Carpathy's idea. Instead of a database, you just give the LM well organized markdown files and it compares it here to the actual semantic search rag. So, actually, I might as well just read it off from here. So it finds it by reading indexes and follows links rather than using similarity search. So we're getting a deeper understanding of relationships because they're links rather than just saying, "Hey, these chunks seem similar." As far as infrastructure, it is literally just markdown. So like I said, you don't even need the obsidian. You just need these markdown files. Whereas with semantic search, you need an embedding model. You need a vector database and a chunking pipeline. The cost over here is basically free. Your only cost is going to be tokens. Whereas over here, you might have ongoing compute and storage. And for maintenance, you just run a lint. You clean up things. You add more articles. You give it more context rather than having to re-mbed when things change. But right now, the weakness of course with the uh LLM knowledge wiki is that it doesn't scale huge across enterprises, right? Because it's just a bunch of files. Um and that is where the cost will probably get more and more expensive than going to something like standard semantic search or knowledger graph or light rag or whatever other tool is out there for that. So here you can see if you have hundreds of pages with good indexes, you're fine with wiki graph. But if you were getting up to the millions of documents, then you're going to want to actually do more of a traditional rag pipeline. Today I'm going to explain the different levels of building your own AI second brain. You can see here we have a visual of three very different types of data. This one is where we have our context really starting to form and we're starting to see some relationships and we're starting to see some different nodes and entities form. And then as we continue to scale this up, add more knowledge, more knowledge, more relationships, we start to get something that looks a little bit more like this, where we have clearly different clusters, and inside of all of these nodes, we can see how they relate to each other. And then over here, we're taking all of those relationships a step further, and we're able to then start to see how everything really pieces together rather than just having files that sort of link back to each other. This is relationship mapping. And so really the idea of an AI second brain has blown up because we're all trying to get as much information out of our heads into our systems as possible. That's the true value. Your moat is your data. It's your IP. But the process of organizing that into a system so that you can use it with a bunch of different AI models and so that it can actually recall things in a way that makes sense rather than just hallucinating or spending a bunch of your time and tokens trying to look through everything. That's the issue. So clearly all of this is my real data and this is what the actual project looks like. It is my Herku project. I have a bunch of folders and files here. And at the end of the day, that's basically all it is. It is markdown files that are organized in a way that I understand and that my agents understand. And so, yes, I'm going to walk you guys through what I have here and how it works. But I also have this other project where I'm going to show you if you're starting from scratch or if you feel like maybe you're in between level two and three, how we can actually look at the differences and what it might look like to scale up your own systems and start to add context in different ways. So, super excited to dig into this today and I don't want to waste any of your guys' time. So let's just start looking at these five levels and how they differ. All right. So every level of a claude code second brain and I'm going to be obviously kind of referring to claude code a lot but keep in mind this can be used with any AI model. I use my second brain all the time with codecs as well. I use it with Hermes agent. This can be used by different agent harnesses because it's just files and folders. So what is the actual job of a second brain? A lot of people probably define this differently, but the way that I think about it is that it's a place for me to save notes, meeting recordings, ClickUp threads, stuff like that. I can save it there and then it helps me basically ingest it and get it into the right spots so that it can actually find it later. And so that's really the thing to think about is can your agent find it again and could you find it again? Because if the answer is no, then you probably don't have the right routing or folder architecture set up, which is what I'm here to talk about today. And one other sort of mindset thing that I want to get out there before we dive into these five levels is that you kind of have to work backwards. You want to reverse engineer based on the question. So this will start to make more sense as we get into it. But really what you should be thinking about is how do I want to use this data in the future because how it's going to be accessed and recalled determines the way that you put it in in the first place. For example, a basketball hoop and a basketball. We know what shape the hoop is and we know that the ball needs to go through. So, why would we ever design the ball to be a giant square? Because it just wouldn't fit through the hoop. So, that would make no sense. So, you need to start with the end in mind a little bit. Once again, I will show you exactly what I mean by that as we continue on. Because remember, we're trying to get to the point where your second brain knows everything about your business, about you, your relationships. It knows everything to the point where it probably can recall stuff better than you can because it has a better memory and it can search through things way faster than you can. So, we've got five different levels to talk about, and they each kind of have different questions. So, level one is, can you find the file or the info by looking for an exact word or name? Level two is, can you pull everything on a certain topic together? Level three is, I searched for different words than I wrote. So, semantic search, you're searching for meaning rather than an exact word match. And then trace relationship chains. Can you ask about topic X? And then trace that all the way back to topic A. And then level five is just kind of making this whole second brain thing super autonomous to the point that you don't even have to think about it. And by the way, this isn't me saying that number five is best. I have some arguments about why I do not currently sit on level five. The point I'm trying to make here is each level is different and you want to find the simplest level or the lowest level that actually fits your needs. If you don't have a painoint in your system, then I don't really think there's a need to go experiment or develop a new sort of, you know, architecture. If there's not pain, then why create more? Okay, so level one is pretty simple and this is where you always start. So you start with a claw.md or if you're using codeex or something, you would start with an agents.mmd. But you start with a cloud.mmd which is kind of, you know, that gets loaded up. That's almost like the system prompt for that session for that project. And then you've just got a bunch of folders and files. But the key part there is the cloudmd is kind of treated as a router. So yes, you've got some, hey, this is your role. Here is what's important. But you also have routing rules. If you ever need to find information about me personally, look in this folder. If you need information about our quarter one priorities, look in this folder. Because if you've ever had a point where you ask Claude to do something, and then it asks you, "Hey, can you give me more info? I don't know what you're talking about, but you know there's files and folders in your project, then you probably just didn't give Claude the knowledge to go look there." It's not just going to go search your entire codebase automatically. I mean, you wouldn't want it to do that because it's going to waste your time and your tokens. So, if it doesn't know if something lives somewhere, then it's probably not going to be able to find it. So, when this is properly set up, you will stop having to reexplain things. You will talk to it and it will just know where to go look and why. But the problems with this is that if it grows too big, it can start to get messy and feel ignored. And this is typically more of like an exact word type of search depending on the way that you route. So, if I open up my um example project here, let's open up level one. So, in level one, what you can see, pretend this is its own cloud project. We've got a clawmd. So let me click into that. We can see here it says this file loads automatically every time you open cloud code in this folder. It is the one file that tells the AI who you are, how you work, and where things live. At level one, this file plus a few folders is your entire second brain. So here's kind of like that basic knowledge. And then right here, it's this simple where things live in the context folder. Always true background about you and how you work. Read this first projects decision log. And that's basically it. So right here, you can see there's a context folder. We have an about me file which you could grow. We have stack and conversations file. We have decisions. So this is a decision log where you can have your cloudmd always append new decisions and the dates whenever you make a big change to your project or to your life or to your business. And then we have projects. So this is where you could have a markdown file or even folders within the projects for all of your ongoing projects, all of your ongoing clients, whatever it is, however you want to organize it. That's where you can have some projects. And you can even start to organize these things by dates if you want. So, if you want to just have one that's for like May and then you have all of those stuff and you have one for June. The thing that I really want to stress here with level one and the thing that I answer a lot in my community in the comments is that there is not yet a standard way that has been proven the best way to set up your projects or your second brain besides some of the most common things like your context and your cloudmd and your, you know, whatnot. But the point I'm trying to make there is don't see what I do and think that that's the right way or see what someone else you watch does and think that that's the only right way. All that matters is do you have proper routing in place and does it make sense to you and does it make sense to your AI? Okay, so let's say I have my Herk 2 project right here and I need to find something in here but I can't ask AI for some reason. what I need to find is easy because I understand the drill downs. You know, I understand my base folders. And let's say I'm looking for the HTML slide deck I built for my ranking cloud code features video. I would come into here and I say, "Okay, I know that's a project." So, I'll go there. Within my projects, I've got another project for YouTube videos. I'll open that up. And now I know I made this video right here, May 30th Claude Code top 50 features. In here, I have the actual tier list deck. And when I open that up, now I have the slide deck. And not only can I find it easily, but my agent can find it because it all makes sense and I have routing rules. Real quick, guys, if you're watching this video, you're probably interested in building your own AI operating system. Lucky for you, I have a full free course on that in my free school community. The link for that is down in the description. Join the free school community. Hop in here, take the 7-day challenge, build your own AI operating system, and apply these principles into building your second brain, which will make your AI operating system even more powerful. So, links in the description. Let's get back to the video. Awesome. Okay, so that is how you start. Now, as you move up to level two, you might be able to start to work in some things like the LLM wiki, which is what I've got set up for a few different things. This is the whole Carpathy LLM wiki, which I did make a full video about. If you want to check that out, I'll tag that right up here. But this is when you start to have more files and and they start to take a bit of a different shape and you want to organize them together in a bit of a different way. So, it could be really good for researching all on a certain project. It could be really good for, you know, a few of the ones that I've got set up is my YouTube transcripts all live in their own wiki. I've got all of like my meeting transcripts that live in their own wiki. So, for example, this is the obsidian view of my wiki for all of my YouTube video transcripts. You can see here if I go to wiki, you can see there's main concepts like aentic workflows, AI coding market, context window, and all of these in here start to relate back to other tools and concepts and videos and stuff like that. So, we've got the sources, we've got platforms, we've got um context management techniques, and all of this was autocreated by our cloud code when I told it to ingest this YouTube transcript into our wiki. So, I'm not going to dive super super deep into all this right now, but definitely check out that YouTube video I linked. Now, what else is cool about this is this transcript wiki actually lives within my main Herk 2 project. So, here's Herk 2. If I go right here to other worlds and then I go down to YouTube OS and I click into the transcript wiki right here. This is what we were just looking at in Obsidian. We could see the concepts. We could see the comparisons. We could see sources, techniques. This is what we were looking at in Obsidian. So all Obsidian is is it basically just visualizes your markdown files. You see here wiki concepts, comparisons, techniques. This is what we were just looking at. All we get now is we just get a visual view of all that. And so the reason I wanted to bring that up as well is because I think a lot of people obviously get pretty infatuated by that visual view. And obviously I started the video with that because I think that's what hooks a lot of people in. But all that really matters is can your system grab that and give it to you. If you are a visual person and you really want that view, then by all means install Obsidian and set it up. It's super easy. But I'm saying that you don't always need that visual layer if it's not beneficial to you. I hardly ever open Obsidian just to be honest because I know that it all lives here and I know that my second brain and my OS can find all of that. So anyways, in level two here, let's look at this. It's very similar in shape to level one. It's just building on top of it because now we have our cloudMD which starts to route to some other things because it routes to the wiki and it still routes to context projects decisions, but it's also routing to references and memory. So we're just starting to add a bit more of these routing rules inside of the claw.md. We can grow the context. We can grow the decisions. We can grow projects and references. And we can also start to get this idea of memory. And what's really cool about this is you can turn on automemory in cloud code. And the AI will basically start to write this file and update it on its own. So you don't even have to think about it. If you come in here and you do /memory, it'll say automemory on or off. And if it's off, if you want to turn that on, just turn it on. And now one thing to think about is I mentioned earlier that we want to make our second brains tool agnostic. And this is one thing that's pretty specific about cloud code is it uses claw.mmd and it uses this memory.mmd and it keeps that updated on its own. So if you wanted to move this over to codeex, what you would do is you would first of all transition your claw.md. You'd make a copy of it called agents.mmd. As you can see here in my herk 2, I've got my if I scroll down claw.md right here and then I've got agents.mmd right here. And they're essentially the exact same file. Just so codex can read this one and cloud code can read this one. But because claude code keeps that automemory, all you need to do is make sure you have that memory MD file and just tell codecs, hey, by the way, for memories, look in our memory.mmd file. It's all about the routing there. Anyways, just felt like that was important to throw out. But at a certain point when you have these, you know, wiks, they do start to degrade a little bit because what's what's great about them is that they have indexes, right? So when your AI starts to look in the wiki, it knows, okay, if the user is asking about agentic workflows, I'm probably going to start here. And then from here, I'm going to drill down and read this to see what else is important to them. Maybe they're asking about the WAT framework, and then I can drill into that. And maybe from there, I need to learn a little bit more about the cloudmd system prompt, and then I will drill into that. So there are relationships here a little bit, but this isn't the same as like semantic relationships or knowledge graph relationships that have more meaning. This is more about just actually following a trail and reading the page in its entirety. And I'll be fully honest with you guys. I pretty much sit my entire Herk 2 project in this level in level two because this has been working really well for me. Like I mentioned earlier, I haven't felt a pain yet big enough to switch over to level two. And here's what I meant by that. My wiki has links. Isn't that a knowledge graph? Not exactly. Because this doesn't have connections of how they are related. like this is endorsed by this or this has cron to here. These just have connections because it's like a a C also. It's like backlinks. So, they're very similar and yes, they can achieve a similar effect, but it's still a little bit different. Anyways, let's take a look at level three, which is where you start to do things like semantic search. Whether you do that in Obsidian, whether you do that with Pine Cone or Superbase, however you start to grab the actual semantic search, that is what level three is. And so just as a quick visual for you guys, let's take a look at this quadrant cluster of images. So every one of these vector points is an image. And what we see in here as the payload is stuff like the file name, the URL, the name of the author or the artist and the URL. But we don't actually see like what's in the image. We don't get a description. So what we have to do is we have to organize these images by meaning or by similarity. So, when I open up this graph and we start to visualize the stuff here, what you see is that we have this main image, these owls, these kind of like I I don't even know. Um, it's a very trippy style, like hallucenic style. Anyways, then this one is kind of similar, right? It's got those colors. It's got the paint. This one is also similar, but they're not the same. They just share similarities. And as we start to expand these more and more, we can start to get into different styles. So, this one has like some creepy eyes and mushrooms or whatever. This one is kind of more down that fantasy lane. And as we start to build out more of these relationships and meanings, we can expand and grow away from them. And so quadrant really just gives you a visualization here. I mean, it's a it has clusters and vector store, but the reason I pulled this up as a demo is just because we start to see the actual relationships form here based on meaning. And that's what's important about semantic search is that we're no longer doing keyword matching. We're searching based on meaning. So here in my YouTube transcript second brain if I go to the smart lookup over here this is very different from just the regular search. So for example if I search here for um feedback let's say we're actually doing a match on the word feedback and it's only showing me where that word actually appears inside of our second brain. But if I come over here in the smart lookup and I search for feedback we are getting matches that have things in here that mean feedback. So live test results, cloud code skills, which was talking about evaluations and stuff. So there's a big difference between keyword matching and semantic search, you know, similarity matching. This one over here is saying X equals X. And this one is saying X is similar to X, Y, and Z. And so this all just goes back to vector databases. I've talked so so much about vector databases, so I'm not going to dive super deep in. And I've got so many resources on my channel, but basically what it is is we take a document. So let's just say YouTube transcript. We chunk it up and then each chunk is ran through an embeddings model. And the embeddings model puts that chunk of text onto like a three-dimensional space where space is related to meaning. And so it decides, okay, this chunk is about a company, so we're going to put it up here. This chunk is about finances, so it's going to go here. And we start to see these vectors form near other similar vectors. Now, do you guys remember how I said earlier like you want to think about how is the data going to be used? What type of questions are you going to ask? This is a reason why that's so important. So, think about this. Let's say I put my meeting transcript of March 5th meeting into my second brain and I put those in as you know vectorized chunks. So, let's say when I vectorize that meeting, we actually get, you know, like 20 chunks. It actually creates 20 chunks or however many that is. And then when I say, "Hey, Mr. AI agent, can you summarize the meeting on March 5th? It will basically search for March 5th meeting summary and it will pull chunks that are similar to March 5th meeting summary. And then even if it gets the right chunks, it's going to only summarize those five chunks. It's not able to look at the entire meeting summary or sorry like meeting transcript in entirety. So it doesn't really know a summary. It might be missing a lot of key information. Now, yes, there are things you can start to play with there like metadata and other things like that to make these results better. But at the end of the day, people kind of assume that a vector database was some magic solution where it could always pull back what you need. But that is very false. And I mean, think about it like this. Let's say we have a table and we say, "Hey, which week do we have the highest sales?" Okay, the agent looks for highest sales. It maybe grabs this chunk outlined in gray of data and then it looks at, okay, week six here was the highest sales, so that must be the answer. But in reality, you can see week 14 was higher, week 19 was higher. So when you need something that has actual full context, then you can't do the vector database chunking. That's where you'd rather just have a markdown file of March 5th and then all this agent would have to do is read that entire markdown file and then give you a summary and that's just going to be more accurate. So in this project, if we open up level three, you can see it's very similar because you can still have context files, decision files, you can still have all that. And then you might identify, okay, actually this one specific unit of my business, maybe my YouTube transcripts, maybe I want just that to be a vector database, but I still want my context and my projects and my decisions to be markdown files. So another point I'm trying to make here is just because you have a second brain and just because you have a massive, you know, folder here with a bunch of folders and files doesn't mean that the whole folder needs to be one style. Doesn't mean that everything needs graph rag. Doesn't mean that everything is just LLM wiki. It means that you're able to decide based on the type of data and the way you use it, how can you structure this specific folder in the way you want it. So here we have a vector index folder and we click on the how search works. It works by chunking, embedding, search, hybrid, reranking. There's some things you can get really, really nitty-gritty on when it comes to semantic search. But what vector retrieval is really, really good at is looking at tons and tons of data, typically just like a lot of text, and when you need a very specific answer, something that's very similar. So, if you had a thousand rules that you needed to store, and you basically said, "Hey, um, can you remind me what rule 17 was?" That might be a really good use case for vector search because it's able to search for rule 17, pull in those chunks, and just give you a little snippet because it would be a waste of time and tokens for your agent to read the entire markdown file of all a thousand rules if you just needed rule 17. So that's kind of the difference there. Like I said, I've got so many videos on vector stuff on my channel, but really you could say, hey to your cloud code agent, I have this data. Here's how I want to use it. Do you think this would be better for now as markdown files, or should I do semantic search? Like what would actually make more sense here? and it will help walk you through the way that you should actually set that up. So now I hope you guys are starting to understand why I said, you know, moving up on or I'm sorry, like moving up on levels, moving down doesn't necessarily mean better. It's all about figuring out what is the pain point with what you're currently doing and where would a different level help you out and fix that pain point. Okay, so now let's take a look at level four. This is where we start to get into like knowledge graphs and relationship graphs, which typically are going to be the most complex and sometimes the most expensive as well. If you're doing it on a certain platform, you could always use open source software. But anyways, knowledge graphs. And I also want to be upfront. I've played with these a lot, but I do not actually use these on the day-to-day because I found out just other ways to use routing files and wiks that fit my needs. Now, my work is very different than what a lot of your guys' work may be. Mine is very project based and it is very, you know, content heavy. I don't have a massive CRM to manage with a bunch of different businesses and clients, you know, and if I did, maybe a knowledge graph would make a lot more sense, and it probably would. But typically, the cool part about that is if you identified that you needed a knowledge graph, let's say for all your projects, you needed you wanted to put all of this in a knowledge graph, the data probably already exists here. And that's the thing about building out these relationships in your knowledge graph is that the system, whatever software you use, is typically going to be pretty good at embedding that and creating that. But the problem that you have to solve is you have to give it enough data. And so one thing that I really like to do is I like to have these brainstorm sessions as you can see. And what I do with these brainstorm sessions is I use a skill called grill me. So if you see here I have a skill called grill me which I originally got from Matt PCO. I customize it a little bit. I'll leave the skill for grill me in my free school community. The link for that is down in the description. All you have to do is hop in here, go to classroom, click on all YouTube resources, and you can find all the skills and everything like that. But the skill, what that does is it basically just grills me. It interviews me relentlessly about a certain topic and it creates a brainstorm file here. It only stops when it knows everything about it. So if you wanted to start building up a knowledge graph for all your clients and businesses, just say, "Grill me about client A, grill me about client B, grill me about business A." And it would just ask you questions and you can feed it files, you can give it stuff, you can feed it in transcripts, you can feed it in, you know, contracts, whatever it is. And that's how you can start to form a lot of data. Hey guys, me again. Real quick, I'm editing this video and I realized that I needed to throw out one thing here, which is that obviously if you're putting all of this data and you're sending it all to Enthropic to Claude models, then that's not [snorts] private. So, if you feel comfortable with that, that's fine. I am putting a lot of my data in there and it is my business stuff and that's what I'm doing. But if you don't feel comfortable with that or you, you know, don't want to send client data, of course you don't, then maybe you want to do that through open source models and maybe cloud code isn't where you have this second brain that has every single piece of information about you and your business and your client's business. So the point I'm trying to make here is just this is what I'm doing. I'm obviously aware of the fact that my data goes to Enthropic when I process it through Claude. And if you guys are doing that, then you should also be aware of that. But there are other options if you can't do that. So I had to throw that out there. I am planning to make a ton of videos here soon about local AI and open source models and all this stuff cuz it's a really really exciting space that I think is going to start becoming bigger and bigger. So yeah, keep that in mind. Back to the video. I think sometimes that's a misconception about how I got here and how people build their own AIOS or second brain is that they think the problem is the system not retrieving it. Great, which sometimes it is, but sometimes it seems like the bigger problem is getting everything out of your brain into the system. So before you blame AI, take a look at your folders and files and say, is this actually holistic? Is this does this have all the nuance that I have in my brain? Anyways, from there, when you open up level 4, you can see that it's it's, you know, very similar still. We're just adding on a few things. You can see here we've added an agent.mmd, which is the exact same as the cloud.MD. And what else is cool is you can literally just reference inside of your cloudmd at agents.mmd. And then you can delete all this because this basically just like injects that file into here. But I just wanted to show that. But anyways, you can see we're still following the same principles. We have a wiki. We've also added a knowledge graph layer. We've still got the same where things live with the routing with all these just regular folders and boring markdown. But boring is beautiful. You can see that our memory is still here. It's starting to grow and we just keep building on top of this. So, one thing we added here as you can see was our knowledge graph folder. And so, what happens here is we get different entities, right? So, like we can see, okay, Jordan is a person, Acme is a company. And then we can start to form relationships between all these things. So Jordan works at Acme. Acme is endorsed by Postpilot. Postpilot is a competitor of Cadently and it starts to build out not only these entities, but it shows you how they're all related. And so that's why when I said that I really like using, you know, this um what's it called? LM Wiki is because I have enough of that feel of all these relationships because I've put so much time and effort into ingesting these in the right way and giving it context. The thing about this one is that it has to read every single file it wants. Maybe it was looking at AI video production and all it needed to know was 11 labs. It still would have read this entire file first. And so that's where sometimes the knowledge graph is actually more lightweight in that sense. And this is the example I showed at the beginning of the video where we have light rag. And forgive me, I'm going to have to blur some of this stuff out cuz this is like legitimately my entire second brain and our business. But as I really zoom in here, and this kind of slows down my computer cuz there's so much. But what you'll notice is that we actually start to get relationships. I probably shouldn't have done this with so much data, but you can see like we have this collaborates with that. We have this builds that. And so if I really started to open up all of these little, you know, circles, we could see what was going on and how they're all related. We can see that our 7-day AIS challenge. It was provided from YouTube. It connects to the onboarding process of AIS Plus. It was developed by Aiden. And so we can basically follow around these relationships as you see. And even though it's pretty much the same data that you see here in Obsidian, we're not getting that same level of relationships between these different entities. So anyways, if you guys want to see, you know, a full breakdown video on something like light rag or um graphify or all the other solutions that there are out there for more of a knowledge graph, relationship graph, then let me know. But that is kind of the difference there. So if you don't need those sort of relationship chains and you're not worried about that semantic type of relationships, then you probably don't need to use something like a knowledge graph. And then level five, we have more of the always on brain OS and something like Gbrain. Gary Tan, CEO of Y Combinator, he created this thing called GBrain, which pairs really well with GStack. But GBrain is kind of the idea of everything we've talked about here, wikis, routing, relationships, tools. But GBrain has kind of that always element because it is like constantly syncing and refreshing memories and adding more stuff. So adding in Gbrain to something like a Hermes agent would be really, really good. You could still do it in cloud code, but you'd have to handle those crons and get all that stuff set up, which is why I don't currently run GBandra at the moment, but I have been playing around with it with my Hermes agent. So, anyways, the point here is that it's very similar to everything else we've just talked about. It's just having that auto updating feel, more of the autonomous always on feel. But I will say another thing that I kind that kind of scares me about that is you have this whole dilemma of, you know, when do you have too much context and when does it get to the point where it's actually doing more damage than it's doing good? And the reason I bring that up is because I am in complete control of what my second brain ingests. I will run a skill to go grab all of my meeting transfers from the week. I will say, "Hey, here's something. Help me figure out like help me brainstorm about this and then let's ingest it together." And for me, I really like being in that control because in my mind, there's a big difference between a few types of data. If you guys remember in my like AIOS videos, I've talked about the four C's. So, context, connections, capabilities, and cadence. And for the second brain, I mainly think about it as just these first two. So, context and connections. And so, when I think of context, that's stuff like, you know, what my business has done. So, if I come into here into my my second brain, and you can see here, if I go to um up at OTAAS, so OTAAS are basically just our projects for the quarter. And so here I can see all the Q1 ones, right? I can look at all those and I can click at them and see decisions that we've made in the statuses. And I can also see Q2 OTAAS. So I can see what's going on here. And my second brain is able to see that because that has been basically those are locked in decisions. This is what we're doing this quarter. And then I'm updating the statuses of that stuff. So that's like context. That's what's going on in the business. But when it comes to connections, if I go back to this, this is more of like the real data that isn't as evergreen. This is stuff that changes. This is like Slack threads. This is emails. this is customer data and that type of data you don't want to ingest into a second brain because that's just noise then then you have to go back every month and like delete old stuff. So the way that I like to think about my actual second brain is stuff that I'm not going to delete. This is stuff that is like okay in a year will it be good for me to have this memory in here? Yes. Otherwise it's just adding noise. So when you're adding data into your project think about it like the context and connections. think about if this is kind of like more evergreen holistic data or if this is more things that are going to change next week. So, you probably shouldn't pull it in, but you should make sure that your second brain has access to go grab it. So, that way if I said to my second brain, "Hey, can you just take a look real quick at what John and I were talking about last week about, you know, OTAA number seven, it would first go to our OTAA file and it would search through there and it it would try to find it there. If it couldn't find it there, it would look through the wiki and it would look through meeting transcripts and see what we talked about there. And if it couldn't find it there, it would finally go to ClickUp itself, pull real data in from me and John's conversations and see if the answer lived there. And so that in my mind is still a second brain because I'm able to ask a vague question and the second brain knows exactly where to look in what order to find that real-time data and then give me back the answer that I need. That's the question I ask myself is does this thing understand where my data lives and where to look and can it give me accurate answers. So as far as finding your level, remember your whole project doesn't fit into one level. Maybe this folder is level two. Maybe this folder is level four. Maybe this folder is level three. Here are some things to think about. If you are reexplaining your setup and you need to find things by exact words or files, look at level one. If you have 30 plus notes and you keep forgetting what's in them, look at level two. That's where you sort of like ingest them and get that wiki with relationships. If your project is just completely whiffing on notes that you know exist and your routing isn't working, then maybe you want to look for something more like a semantic search that doesn't rely on an exact word level match. If you're looking for relationships and to be able to follow chains of questions and thoughts, then you probably want to look for something like a knowledge graph. And if you're running agents offline and you've got so much data and you want to sync up a bunch of Hermes agents together, then you probably are looking for something like Level Five, something like Gbrain. And another topic that I get some questions about, which I'm not going to fully address in this video, but I will briefly bring up is the fact that you are building your own second brain OS. So are other people on your team. The next question is how do you actually make sure that everyone's data is syncing together and how do you have more of like your team second brain? There's a lot of different ways to solve that. I think once again it's not an issue of oh do we use Google Drive or notion or GitHub or cloud plugins. I think the issue to figure out with your team is how do we actually make sure that we all habit shift so that this stuff is actually useful and not just noise. How do we make sure that process owners are updating their docs and syncing their stuff there? How do we make sure that other people are pulling from that rather than always just pinging the same people for questions and answers all the time? I think the adoption and the change management question is the bigger one. The tech and the way it actually functionally rolls out is a little bit less. But what I do know is that you getting set up with your own first and understanding how it works, how you should route, how you should make the decisions of where the data should live, that's the first hurdle. You can only solve the teamwide problem once you feel comfortable about the way you run it every single day and that it works for you. All right, sweet. So, you guys have heard me earlier in this course talk about one of my skills called the grill me, which was inspired by Matt PCO's grill me skill as well. So, now that you're thinking about building out your second brain, I want to talk about this grill me skill that really helps me get more context into my systems, but also helps grill me on before I'm going to build an automation or before I'm going to build a new skill. Whenever I want to extract what's in my brain and get it into my second brain and get it into my AIOS, I like to use this grill me skill. So, let's talk about that real quick. The toughest part about building good skills and building a good operating system is trying to get everything from your brain into your system. So, for example, what you're looking at here is after months and months of me building up all of the knowledge that lives inside of my AIOS. It's basically just the idea that if everyone's using the same model, so if everyone's using Claude Opus 4.8, then everyone's going to be using the same prompts and getting the same output because the model is fundamentally the same for everybody. So what really makes the difference is when you add context into that model and you give it your taste, your voice, your decisions, and that's how you get outputs that actually sound like you. But once again, the real challenge is still the extraction, getting everything from your head into the AI system so that your skills can use it and that your context is better. And if you guys have been following me for a while and you've seen videos I've made about like discovery calls and and scoping out projects, that's the toughest part is especially if you're working with a client, asking them so many questions about this process to the point where they might even get annoyed because you're asking so many questions. But that's just what you have to do. It's the difference between a system that is successful 95% of the time and one that's only successful 80% of the time. So this one skill we're going to look at today is called grill me. It basically takes what's in your head into reusable context for your AI. So what happens is all of that knowledge that's in your head that you might think, "Okay, I'm just going to brain dump into clawed code for 5 minutes and it will be good enough, it's not ever good enough." So what this does is it basically relentlessly asks you questions. It grills you until it knows pretty much everything about the process. It'll ask you a question, you answer it, and then it basically will checkpoint and it will write everything back to a knowledge dock and it will just keep going over this loop endlessly until the knowledge dock is good enough and there's no gaps or holes in that knowledge. And so, like I said, this results to better skills, better context, and better projects. And originally, this skill was built by Matt PCO. And what's cool is if you look at it, it is a super simple prompt. It's like four to five sentences. Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one by one. For each question, provide your recommended answer. Ask questions one at a time. If a question can be answered by exploring the codebase, explore the codebase instead. And I like to look at that because it makes you realize that a skill doesn't have to be super complicated automation. A skill can just be a prompt that you don't want to have to say every single time. And of course, naturally, what did I do? I destroyed that. I ruined the skill. I made it a little bit more complex, but I added something that I think makes it much better. So, if I go into mycloud, I go down to my skills and we look for the grill me right here and I open up the skill.md. You can see it's a little bit longer now. But basically what I did is I worked in that whole element of checkpointing after every single question because originally the skill doesn't do that and what happens is if you are talking you know if it's grilling you for an hour plus which sometimes it will and that's a good thing and as the condex window starts to fill up I started to get worried that it was going to misremember some of my answers from earlier. So I just found myself telling it manually hey write this to a doc write this to a doc checkpoint every time. And so I figured okay why not just work that into the skill. So now what the skill does is it creates a folder called brainstorms and it does this at the root of your project. So if I go down here, you can see I've got a brainstorm file or sorry a brainstorm folder right here with these four brainstorms. And so it will create that for you if you don't have it. But if you do have it, it will just chuck a doc in there, a markdown file right away. And so then if I open up like for example this packaging one which I was doing, it will find like the algorithm, the key decisions, but then it will also show you the step-by-step Q&A log of the questions that it asked and what I answered with and the key highlights. And then as soon as we finally got to the end of that packaging grill me session, it said, "Hey, I noticed you have this packaging guide and you have a packaging skill and there's a lot of nuance here that we talked about that's not in there. So do you want me to update both of those?" And then I said yes. And now those skills and docs are so much better. I also did one where I said, "Hey, I want you to understand everything about the business." And we walked through from beginning to end, all the decisions, all the processes, and now my OS just feels like it knows even more about the way the business works. And so, if you think about it like this, right, like nothing is going to be perfect on the first try. And so, let me just do a quick visualization. This is kind of the old way when you're building a skill, right? So, we've got iterations down here. Let's say by iteration one, after you've knowledge dumped in your brain and you want to build a skill, you maybe get somewhere. or let's just say around here where you're about like 70% successful on iteration one and then what happens is you run the skill and you make a small improvement and now you're up about I don't know right here like you go up from 70% to 75 and then every time you iterate you get a little bit better with each iteration until maybe you cap at the point where you're about like 95% good and this could be 10 iterations it could be 30 iterations it however many it takes for your skill to feel a bit more battle tested and honestly I don't think you ever get to 100% because as your business evolves and as you evolve, the skill keeps evolving. So like all my skills that I've been using for months and months, I'm pretty much still changing a lot. But the whole idea is what if on iteration one because you do this grill me and you spend extra time up front, you're able to jump right up here to like 90 at the beginning. And yes, it's not perfect. You're still going to iterate a little bit, but you're just there a lot quicker, which gives you more opportunity to find better ways to iterate on it. So that's my horrible visual of why I think this is valuable. It just goes back to that whole idea of if I had six hours to chop down a tree, I would spend the first four sharpening the axe where upfront, yes, maybe it feels boring or repetitive, but that's what you need to do is get all that context in there because it helps downstream so much more. So anyways, if you guys want to grab the grill me skill, you can look it up here from Matt PCO. Or if you want my version, you can come to my free school community. The link for that is down in the description. Just join the community, go to the classroom, click on all YouTube resources, and it will be right in there for you to find along with all my other free resources. And then it's as simple as saying, "Hey, grill me about this." Or, of course, you can invoke it with a slash command. Right there, you can see, "Grill me." But I could just say something as simple as, "Hey, I need you to grill me about the way that I think about applying AI to my own business internally in a safe way that won't damage the business." You can see it'll obviously load up that grill me skill. We're going to see in a second that it's going to create the capture file so nothing gets lost. Right there we have applying AI internally. And this is what it looks like. It's going to set up the discovery notes, the summary key decisions, um, Q&A log, and any open flags. And what's cool about this is it'll flag things that you need to go find. So, when I was running through this funnel map, you know, there were some things going on in the business that I don't actually know super well. Like, I can't explain the same way as the actual stakeholder or operator that does that process can explain it. So, it said, "Hey, here's some things to flag. Go reach out to this person and have them send you information and then come back and drop that into me and then we'll update this brainstorm." So that's basically how it works. It might ask you five questions. It might ask you 30. It's just going to go until you guys feel like you have the same shared knowledge and that it is a good stopping point. And the cool thing is because these are saved as docs. You can reference them later. But you could also come back to like for example packaging. Let's say I I find a major breakthrough in the way that I package my content. I would just come back to this doc and say, "Hey, grill me again. Here's some new things I found. Let's update all this information." All right. Let's talk about agent teams. What do I mean by this? I basically just mean how can you just leverage a bunch of cloud agents running at the same time creating a team and typically when I want to go for an agent team I've got one reason and that is because I want multiple perspectives. I want multiple different types of agents that have specialties in different areas to collaborate on something together. Now there is one important thing to understand about agent teams. There is a big difference between sub agents and agent teams. Take a look at this visual. On the lefth hand side, we have sub aents. On the right hand side, we have agent teams. Now, we've already talked about sub aents. You guys understand this. The main agent orchestrates sub aents with fresh context windows. And the sub aents cannot talk to each other. They can only talk back to the main agent. They can only report to the main agent. But in agent teams, look at this. The main agent spins up the team and there's a shared task list. And now all of these specialized teammates can communicate between each other and they can claim tasks off the list and they literally can work together and talk to each other and report back to the main agent. So it's just a lot more of a team rather than like individual workers in cubicles that don't talk. These are actual, you know, people sitting around one desk having a meeting talking and getting work done. So it's very cool, but it is a little bit more token intensive. So I don't use them all the time. Like I said, it's a very specific scenario when I want to have a bunch of different perspectives collaborating together in real time. Now, if you want to do stuff in parallel, you're probably better off just spinning up a dynamic workflow. So, a dynamic workflow is really cool because what it does is it takes the main session and it basically creates these dynamic workflows of agents that will do different phases. So maybe it'll spin up five for the planning phase and then maybe it'll spin up like 10 for the next phase and it will just dynamically spin up more phases of sub aents based on the results of the previous session. So it is very cool. It's it's also quite token intensive, but it's a great way to do like verification loops and to make sure that everything is working as it should. So um I do have videos on my channel about dynamic workflows. I'll tag one right up here if you want to check out like kind of I break down how it works. But those are all sub agents still. Now, what if we want agent teams that literally, as we know, collaborate with each other, talk to each other, and all report back to the main session, and maybe they have some sort of shared task list together. I mainly have one key use case when I make agent teams because typically I can I find that things can be done in parallel. But let me talk about my use case here. So, I like to do councils or war rooms or, you know, something what I call a roast. The idea is whenever I'm having a big decision or whenever I'm trying to analyze if something is going to resonate with the audience or you know if there's any holes in my plan, I like to spin up a debate team of different agents that literally talk to each other and debate and they go back and forth and chat and chat and chat until they reach some sort of consensus. And I just think that it's not only pretty fun, but it gives me different angles and then I'm able to read the debate and I'm able to read what did different perspectives bring up. Now, before we actually do that, I have to show you how you set up agent teams because if you go to the documentation, you can see that this is an experimental feature that is disabled by default, at least at the time of making this video. So, you have to enable them by adding a config to your settings. So, look at this. All you have to do is you have to add this environment variable cloud code experimental agent teams equals 1. So, what I'm going to do is copy this. I'm going to go into our knowledge work project that we've been working on together. You can see in here if I go to the files and I go to my.claude. We don't yet have a settings.json file. So we're going to have to create that. But here's what I'm going to say. Hey Claude, I want to test out agent teams which is currently an experient or experiential an experimental feature from cloud code. So take a look at this environment variable. And I'm just going to paste that in. The documentation told me that we have to put this inside of our local settings, the JSON file for this project if we want to use agent teams in this project. So inside of my do.claude create the settings file and add this to the config so that we can actually use agent teams. Okay. So I'm going to shoot that off and hopefully it's able to understand that request. It's able to create us that settings file and then we'll be up and running with agent teams. You can see it's even running a skill right here that's called update config. Okay, awesome. So it created that file. If we go in here and we just verify that in thecloud we have a settings.local.json and there it is right there. Perfect. Now, what we probably need to do is reset the session. So, I'm going to clear that out. A lot of times when you add a new config, you have to start a new session in order to be able to have those changes actually take effect. So, let's see what we can do real quick. I pulled up this report. It's a 2026 CEO study by IBM. They surveyed a bunch of CEOs and asked about some AI stuff, which I've broken this down in a few different videos. It's super super interesting. So, if you want to check that out, just Google this 2026 CEO study IBM and give it a read. Super interesting. Anyways, what I did though is I downloaded this PDF. So, I'm going to just pull up my downloads real quick. And what I like to do is I like to just copy the path to the file that I want my agents to look at because it can obviously access your downloads. So, I copied the path. I'm going to go back into Claude, paste that in there. Now, I'm going to say the following. All right. So, I just read this report and I think it's really interesting, but I'm having trouble understanding how to apply the insights to my day-to-day. So, what I would like you to do is I would like you to create an agent team using the team create function to create an agent team. I want this agent team to have different personas. So, I'm thinking maybe like a small business owner, a large enterprise business owner, a CEO, and maybe a entry-level employee. And then any other personas that you think would be interesting to have inside of this discussion because I want them to debate about this report. I want them to analyze what stats did they think were the most interesting and what was the most concerning and I want them to go on a couple rounds of debates so that they can basically give me an analysis of how I should use it for me and my business. Now I know you don't know too much about me at the moment. So go ahead and look through my Herk 2 project so that you can see who I am and what my business does and then make sure all of the insights and the debate are tailored towards me personally for me and my business. Okay. So, the reason why I said that so specifically up at the beginning where I said use the team create function in order to create an agent team is because sometimes if you say an agent team, it might just spin up a bunch of sub aents. So, you have to be specific about agent teams that can actually talk to each other. And the good news is you'll actually be able to see when it does that. Okay, so one thing I wanted to call out is that agents don't like to read PDFs and like HTML as much because there's a lot of metadata. So, what it did here is it converted that PDF to text. If you see right here, it converted it to text and then it read the text. So anyways, you can see here it says, "Before I spin up the team, let me stage a shared brief." So all personas debate the same facts and they all tailor to you specifically. So it's going to write up that brief and then it will spin up the agent team and I will point that out to you guys. Okay, here we go. So it is launching six distinct personas round one and it's going to run all six in parallel. So that word kind of scares me because I'm not sure if it fully understood that we want the team. Let's see what it does here. Now, as you can see these different personas being spun up. What's cool is you can click into them and you can see the actual prompt that was shot off. So, this is the prompt that was sent off to this specific agent, but it looks like this might not be a team. It looks like it's just spinning up six sub aents. So, I'm going to stop this real quick and just verify that it, you know, it understands me correctly. And that is something that you should do. Watch your agents as they're working and they're building things. And if it feels like they're going off the track that you're trying to put them on, then stop them and explain. So, it looks like you're creating just sub agents and you're just running those in parallel, but they can't actually talk to each other. And I wanted you to use the agent team function, team create function. So, you can actually create an agent team that can all talk to each other together. So, that's super important. Please make sure that you're doing it that way. Okay. So, I was correct. It was doing it wrong and it was able to do a little more research and correct itself. Now, quick quiz question. What would you do now? If you said build a skill around agent teams or if you said something like put this in the cloudmd, then I would say you're right. Whenever it misunderstands you, correct it and tell it to update instructions, update skills or create a skill so that that misunderstanding doesn't ever happen again. Remember? So that's what you should do after this message or even start up a new session and say, "Hey, here's what happened and here's what you did and we need to make sure that it doesn't happen again." So anyways, let's see what it's doing now. It has these six different personas that are being spun up and these are personas that are going to be able to actually talk to each other. You can see that it's sending off different messages to these different personas. So anyways, now that we know that they're able to actually talk to each other and debate the way we wanted them to, I'll check in with you guys when this is completely done. Now, the other thing to remember real quick about this is that this isn't going to fill up too too much of our actual context window, but this will eat at our 5-h hour limit because all of these agents, you know, they're on their own context windows and they're eating tokens and they're talking and agent teams are expensive. But just wanted to call out once again that these agents are talking not in our main sessions context window. All right, so that finished up. I'm not going to read this entire thing and every single round of debates because that would be boring and take forever. Let's just go over some of the key facts. So, six personas, three rounds, real cross talk. We had a small business owner, we had a chief AI officer, we had founder, CEO, we had a bunch of different roles, right? So, as far as the stats, each of the different personas pulled out one that was the most interesting and one that was the most concerning. We saw the team's collective verdict after they argued it was that the most interesting stat was the reality gap. 10% today versus 72% by 2030. It's the one honest number in the deck and it's your product market fit written in a footnote. The most concerning stat was the 25% use versus 86% skills adoption gap. It's your own risk. The same disease as your 20% AI plus churn and your single most sellable lesson all at once. And the most overrated was the plus 17% headline. So anyways, they had to agree on this stuff. They had to all come to a consensus on these stats. And now it gave us basically actionable steps because it knows me. So audit your own agents before you sell a cert about auditing agents. Turn the Nate to John handoff into a one-page decision rights map. fix 20% churn, ship a free AI adoption at audit, and adopt Gordon's credibility guardrail on every citation. We could dig into this, right? And we can have a full report written up, but the point I'm trying to make here is getting different personas is really nice because you have subject matter expertise in one or maybe a few areas, but you don't you can't see everything. You can't see around every corner because of your experience and because of your knowledge, but other people can. And Stanford actually proved this. They have a research method called the storm method where they have different personas attack the angle and find the holes in it and then it has been proven that it's much better research and much more thorough research. So, I did a video breaking that one down as well. It's called the storm research method and I'll tag that video right up there if you want to check it out for next time you're doing research. But just thinking about the idea of using different agents as individual specialized experts that can help you create better plans, create better products, create, you know, have better ideas. What's really cool about this, this wasn't planned, but the next thing I wanted to talk about on here was artifacts. So, it's cool because at the end of this message, Claude says, "Do you want me to package this into a sharable artifact, a clean one page that you can revisit or send to other people?" So, basically, the way that you used to share information is you would create slide decks or you would create like a little memo or I don't know, however you like to send information to your team, that's what you would do. And a lot of times when you would send those artifacts, they would be static, meaning you would download it, you'd send it over, they would open it, and if you made changes on your end, it would kind of, you know, you'd have to send them an updated version. But Claude recently dropped these things called artifacts where it's able to package everything up into a pretty HTML style and then it will just give it to you on an actual URL, meaning it's live on the web and you don't have to host it. It's literally just Claude will host it for you. So that way whenever you have artifacts and whenever you've been brainstorming with Claude for a while, you can say, "Hey, put that into a quick artifact so I can send it to my whole team." And then what's cool is if you keep updating it on your side, as soon as you update the artifact, whoever is watching it, it will update on their side, too. So, it's a really nice thing to be able to utilize, especially if you're working on projects with your teams. I'm not going to spend too much time here because it's a pretty simple concept, but I definitely wanted to bring it up. So, on this lefth hand side, you can see if I click on artifacts, I only have one right now because it's a pretty new feature, but let me open up this artifact to show you. This is a URL. So, if I gave you guys this URL, you could actually see this as well. I guess actually you have to be in my organization to see it, but either way, the point is it's live. It's not a local host. It's a real URL. And so this one I had it spin up to prove to me that the spacing on our book was correct. So it was proving to me against like The Great Gatsby and it was showing me the indentation and the spacing and all that kind of stuff. And this is not itself a really impressive artifact. I just wanted to show you that Claude basically hosts these. You can switch between them. You can rename them. You can see the different versions. You can copy the actual prompt to edit the artifact. And like I said, if I go back into the app, you can see that you will be able to manage and view all of your artifacts right here. Copy the link, send them over to your team. All of these things over here, these are not artifacts. These are just different chats or different projects. These are the artifacts. All right. So, we have our artifact fully built out. As you can see, all I had to say was yes, turn that into an artifact. So, it used all the context and it used all of the rounds of debating to help us build this out. Um, let me just go ahead and open this up on an actual URL. So, here is the actual link. As you guys see, this is something that I could send to my team very easily. I'm going to open that up here. Rewiring the seauite translated for one 15 person company. So, this was our agent team debate on this study. We can see the verdict. We can see the stats each seat fought over. We can see the round table with the different personas. We can look at the five moves. So, we could really just dig in here and I could obviously, like I said, if I wanted to show my team what I had worked on today or show them something interesting that I built, I would just send that over. Super super easy, super super quick. Awesome. So, that is artifacts. Very very cool. Let me go ahead and cross this out. We are really making some great progress on this course today. So the next thing you can see down here is routines. And routines are absolutely awesome in the desktop app. It's really, really easy to manage them. I click over here on routines. You can see different routines that I have. And what you'll notice over here is that some are paused. You'll notice that some are cloud. And then you can also spin up ones that are local. And so really the big difference is that the local routines, they have to be running locally. So your cloud code app has to be open and your computer has to be on. But if you put them in the cloud, then all of this can be turned off and they'll still be running on the cloud whenever you want them to. So if you want them triggered on a specific, you know, day and a certain time, it can be that. It can also be triggered on certain actions. Now, the one thing is you are limited on how many cloud routines you can have active. I believe it's like 15 per day can be triggered, but they're super easy to set up. And what's awesome is you get the full agentic loop. So, I'm about to shoot you guys over into a video where I break down these routines and how to set them up. It's completely awesome. Cloud Code has finally brought us routines, which basically means you can inject a prompt into Cloud Code, but it can be running on the web, so your laptop does not have to stay open. And I'm so excited about it. I've already been playing around with it. I've been migrating my automations over there, but there are a lot of little gotchas. So, I'm here to explain exactly how you can actually set up these automations so that they work. So, today, April 14th, Claude tweeted, "Now in research preview, routines and cloud code. You configure a routine once, which is basically like a prompt, and it can run on a schedule, from an API call, or in response to an event, and it runs on Anthropics web infrastructure. So, that's awesome. So, you can call a routine from an API, you can have GitHub events trigger it, or they can be scheduled, which are like the scheduled automations that we already have, but now they run on the web. So, you really can create these from anywhere. You can do it right here as a scheduled trigger to run scheduled remote agents, which is in the terminal. You could also go to cloud.ai/code. So, you could do it on the web. web. And right here, you see I have three web- based routines right here. Or what I'm going to be showing you guys today is just doing it in the desktop app. Because right here, if I go to my scheduled tasks, you can see that I've got some like these four that are local. And then I've got these four that are running inside of a GitHub repository. So these are the remote ones. If I go up here and click on new task, this is where we could set up a new local task or a new remote task. It's very similar. You set up the name, you set up what Claude should do, and this is the actual prompt. So I'll talk more about that in a sec. But then you would configure your model, your repository, and your cloud environment. You set the cadence hourly, daily, weekdays. I think the minimum is once an hour. Like you couldn't go like every 10 minutes or something, but still not bad at all. This is where you could configure all of your connectors. So if you need to connect Slack or Gmail or, you know, whatever it is, you can connect them right here. But you can also just do your regular API endpoints with your API keys. And then of course, you've got your permissions. So you can choose how Claude should be acting. Now, the one thing about these are these are meant to be a oneshot prompt. You're not around. So, you probably want to make sure that it doesn't ever have to stop and ask you questions. Otherwise, what's the point of the automation? So, like I said, there's tons of things to dive into here, and I'm not going to try to bore you guys, but some of this is really important because when I first got this set up, my automations weren't just migrating over and working. So, I'm going to tell you guys the issues that I ran into, and hopefully answer everything that you need to know so that you won't have to go into the comments and ask these common questions. I can just answer them right here for you. So, let me just first of all, real quick, show you guys what I tested out. The first thing I wanted to test out is if I came in here and I created a new routine for just shooting a message to my ClickUp. Obviously, that's not any value, but I just wanted to see how it worked because what I wanted to do is see if I could do this without adding my connector of ClickUp. And I was able to actually get this to fire off, but it didn't work right away. So, let me show you guys what I ran into. So, the way that this works is you need a GitHub repository to sync it to in order for this to actually run. So, it's going to clone my Herk 2 project right here in the web. It's going to be able to read my cloud.mmd. It's going to be able to read my scripts and my skills. And then after it finishes the job, it basically just destroys that little cloud GitHub clone. But as you guys know, you don't push your secrets into GitHub because if you see here, my my Herk 2 project, this is my ENV file with all of my API keys and this is listed in the git ignore, which basically says, hey, when you push to GitHub, you don't include these files. So what that means is in here if this is only looking at your GitHub repo, there's no ENV. So how do you get your API keys into this routine that runs on the web? Well, what you do is inside of this scheduled task, you have a cloud environment. So if I click on this one, you can see this one is called Nate Cloud. So if I open up the settings, what do you see? You have the name of this cloud environment, you have the network access, and you have environment variables. So right here is where I put in my YouTube API key, my ClickUp API key, any of the other API keys that I need to give this cloud environment access to. And then the other thing you have to do is you have to look at the access levels because right here you can see that this one is on full, but by default this will be on trusted, I believe. And that means you can only download packages from verified sources from Anthropic. And when we talk about this later, I'll have a link which you can go see all of them. You could even do custom if you wanted to allow specific domains that aren't on that list. But in order for ClickUp to work in this case, I had to go on full because when I went on trusted, it said, "Hey, we can't actually do that." But when I changed this to full, it let me send a message to my ClickUp. And that is how I got this message right here that says, "Just testing that the remote tasks work and the credentials work." So basically, when these run, whatever you have here as your instructions is what gets prompted. And that's exactly the same way that the scheduled tasks locally work. So right here, you can see I say send a message in the internal ClickUp channel. And right here, the actual thing that it says was send a message in the internal ClickUp channel. So, think of a scheduled task or a routine as you basically typing in a prompt and then someone coming in to your laptop and typing it in for you. So, it's the exact same type of interaction as you talking to cloud code. But that's why once again, you want to make sure it's specific enough so that it can basically oneshot it. Okay. So, let's take it a little deeper. Now, what I tried to do is I did another one which I wanted it to be able to use the YouTube data API in order to grab some YouTube comments for me and give me a little analysis in, you know, ClickUp or whatever. So, this is the prompt I said, right? Analyze 50 of my most recent comments from YouTube and give me a quick bullet rundown. My YouTube API key is available as an environment variable. Use it directly from the environment. Don't look for av because what happens is in your repo, right? So in this Herk 2 project, um, when I normally run this, it grabs all my API keys from thev and maybe it reads the claw.mmd and realizes that's where a lot of those live. So by default, it's maybe going to try to look in thev and it's not going to be smart enough to figure out. And so for ClickUp, it was fine. It figured it out. But for some reason with this YouTube one, it didn't. So I had to explicitly tell it, hey, look in the environment variable rather than in the env. So you can see this first time I ran it 1241, I didn't say that and it couldn't do it. It said like, "Hey, I can't find that. I'm getting an error." And I even tried to tell it here and it still didn't work. But then on this most recent run, when I updated the prompt a little bit, it was able to fetch it right away using the API key. And now I have a remote, you know, routine that would work. Obviously, I need to update this. I'm going to migrate over my other automations, but this was just for testing purposes. And then another one that I do is I have some automations here which basically opens up a browser using Playright CLI and it does some stuff in my school community because there's no publicly accessible API. We've kind of figured out a way to automate it without using browser. I'm not really going to dive into that right now. But what I wanted to tell you guys about that is I tried to basically move over this school wins engagement post or sorry automation into a remote session. So, I copied the exact same prompt that was in my regular scheduled task. And then I just added this little snippet at the end. But what happened is this wasn't working because it basically said, "Hey, you know, like when you do this, it spins up a browser, but there's no cookies because all of this is running remotely and all I have to look at is the GitHub repo. I can't look at the local, you know, cookies that we've used in the last couple sessions of this automation." And so, it doesn't seem like this would work because once again, it has no access to that stuff. So if I wanted to do an automation like this, I would have to use um an endpoint that takes authentication in the form of like actual cookies or a header or you know like an API key because every single one of these runs is going to be stateless and after the run the GitHub clone just gets deleted. Now the exception of that is if the automation is changing something in your codebase or doing a review. If it does do that it will create a new branch for you or it will give you some sort of output and not just delete everything that it just did. But for an automation like this it would just delete it. But hopefully after you guys have seen those examples, you now have the ability to come in and you know make some changes if you need in order to make sure that your automations are running. And what I mean by that is you understand this should be a very specific prompt. This is how you change the model. You have to have a GitHub repo. You can change the settings for your cloud environments right here. You set the schedule. You add any connectors you might need, which would honestly be a little easier if you added just like a Slack connector. And then you can set your permissions here. Now, the other thing to be aware of is you do have limits. So, if I come over here to my settings, you can see if I go to my usage, we have our regular session limits, our model limits, but for additional features, we have daily included routine runs. And I haven't run any yet on the actual schedule. I've just been testing them. Um, but we are at zero for 15. So, I could only have 15 automations running with routines per day because I'm on the max $200 a month plan. Your limits would be less if you're on Pro. I think maybe three or maybe five. I'll I have that information later on, but just something to keep in mind. All right, so let's just dive into a little bit more of the details here that may answer some questions you guys have. I think it's pretty clear at this point what it is. Um, I'm going to give you guys this entire doc as well as anything else I've talked about in my free school community. The link for that is down in the description. So, some of the stuff I may not cover. If you want to read more about it, then just go ahead and grab that free resource. So, we know what it is. I think we know how it works, right? Like you define a routine, which is a prompt. You connect a GitHub repo. You could also trigger it by APIs or by a GitHub action and then you can connect your connectors and basically it acts as you talking to your own cloud code. Because of the fact that this is working off of a cloned repo, it's going to read the cloud.MD file automatically every time. So if you have a massive project like a Herk 2 project for example with tons of context and tons of stuff maybe you don't want to put that repo into the cloud to be a routine run because there's a lot of context in that cloudmd and in that whole GitHub repo that might not matter for this automation. So maybe you're better off setting up a specific GitHub repo per scheduled routine. But of course, cloud.md best practices putting in the information that's important because this stuff is going to drain your cloud code session limits the exact same way as it would if you were open up in cloud code just talking to it. So once again, three trigger types, schedule API, which I think is really cool. You could have a different automation make a post request to some sort of routine. And then of course GitHub so you can have it automatically fire off kind of on a web hook based on new PRs, new pushes, new issues, new releases, things like that. So how does this compare to what already exists? We have routines which is the new feature. We have desktop scheduled tasks and then we have something like just a /loop command. So routines run on anthropics cloud and these other two run on your machine. Do you need the machine on? No, for routines that's huge. But for desktop scheduled tasks and for loop, you need your machine on. Do you need a session open? No, that's the same across all three. Do they survive across restarts? The first two do, but loop does not. That has to live within a specific session. Local file access, no, for the routines because it works off of the GitHub repo. And for the next two, yes, you have local file access. Permission prompts with routines, it's fully autonomous. And for these two, they are configurable. And then the minimum interval routines is 1 hour. And these two are both could go every minute if you want. Okay, so let's talk about the environments. Obviously, your ENV is get ignored unless you push it into the GitHub repo. You know, ultimately, if you push it into a private repo, you're probably okay, but you want to be really, really, really careful because then, you know, there's history there and if other people, you know, end up collaborating on it, you just don't want to do that. So, you want to put your API keys in the environment variable like I showed you guys earlier. You want to look at the network access, whether that is full or trusted or none or custom, and potentially some setup scripts. So, that's not something I showed you guys yet. If you're creating a new remote task, you can do a setup script, which is basically just a script that will run when this new session fires up before cloud code launches. So if you need to install any packages or anything like that. Okay, so what's the difference between trusted and full? So trusted only reaches the known vetted services from Enthropic, which I thought I linked right here, but I just linked it there. This basically shows you all of the different domains that are allowed. So right here you can see we've got enthropic services, we've got version control, we've also got some cloud platforms like Google, stuff like this right here. These are the ones that are kind of already verified. So what is the risk of going on full? Well, if claude reads malicious content during a run, then it theoretically could be tricked into sending data to an external server and with trusted that outbound request would get blocked. Now practical risk for private repos where you control the inputs is very low, but I definitely just wanted to at least acknowledge that. So connectors, this is different than just adding your API key. This is more of like the connectors you would add to your actual claude chat or like claude co-workth into like Slack or ClickUp or stuff like that. Here are some security details. I'm not going to go super deep into this. You could also do some more research and download this doc. But of course, there are some things to be thinking about like your API triggers or what's going on with your GitHub repos and the branches because once again, everything is going to be running as you. So if you're not testing out these routines before you just kind of send them off every hour or something, you just have to be thinking about what could happen without permissions and you know stuff like that. Limits and quotas. So it looks like on pro you can have five runs a day. On max you can have 15 runs a day and on team and enterprise you can have 25 routines a day. If you hit the cap the orgs with extra usage enabled can exceed it on metered overage. And then we have the minimum scheduled interval which is one hour. And there are also resource limits. So every one of these routines in the cloud runs on four vCPUs, 16 gigs of RAM, and 30 gigs of disk space. So once again, just be thinking about are you putting an absolutely massive GitHub repo up into the cloud right now to run. That could just be wasting resources for no reason. So what persists versus what gets destroyed, the cloud branches gets pushed to your GitHub repo and the session also stays. So as you saw, if I came into here and I looked at all of these tasks, I could see all of the past runs and I could go look at them to see if something's going wrong. but the actual cloud environment that gets cloned will be destroyed. Basically, the rule of thumb here is if something's local or if cloud code can't reach it in your GitHub repo or via an API, then it won't work. We already talked a little bit about writing good prompts, but you definitely want them to be more specific. For example, with my um scheduled automation here, this is much more specific, right? I have a skill that I want to run. I give it the order of operations, but something more like this YouTube comments one, this is not what you'd want to put in there unless you were defining a skill to just let it run because once again, this is supposed to be a oneshot prompt. So, you wanted to make sure it gets it right on the first try. Okay, so why is this so exciting and why does this beat normal automation? Because we are actually keeping the agentic framework. If you if you know when I talk about the WAT framework where we have workflows and agents and tools, when we actually push those automations to the cloud and it's just a you know sort of a Python script, we're losing the agentic piece. We're only sending off really the tools and the workflow. But in this case, we're keeping the WA and the T all running together because the agent is looking at the, you know, cloudm. It's looking at its scripts and it's figuring out what to do. And if it runs in errors midrun, it will selforrect. And if you configure it the right way, it will be able to sort of like leave a memory trail and it can leave like, you know, updates even though each run is stateless. You can still have them kind of continuously get better. And real quick, let's speedrun through these common questions. Do I need to know cron syntax? Nope. You just can schedule a natural language. Super easy. Can it access my local files? Nope. It only gets what's in your GitHub repo or your APIs. What model does it use? You can choose any of the models as you guys saw. Can you watch it work in real time? Yes, you can hit run now and then you can obviously watch it go right there. Same way you would in Claude. You can even talk to it after it's done or interrupt it and then continue going. Can it use my MCP service? Yes, that is what the connectors are. Can teammates use my routines? Nope. These belong to your individual account. You might be able to share those if you're on a team plan, but I haven't actually yet tested that myself. What's the cost? It's just your normal subscription usage. So, keep that in mind. What happens when a run fails? Every one of them will be stored in your history. So you can go see why they failed. You could maybe even have it at the end of every single routine, say, "Hey, if this does fail, just shoot me a Slack message to let me know." Things like that. And can I test a run before going live? Yes, in fact, you should test it multiple times before it goes live. You just go into the routine, you hit run now, and then it will pop up as running. And then you just watch it, you know, watch it go through its order of operations, and you can inject, and you can help it correct itself so that you have confidence that once it shoots off the prompt next time, you won't have to get in the way at all. But anyways, that's going to do it for this one. I hope that those tips and some of the examples that I showed you were helpful and now you can go off and try to migrate your scheduled tasks or any other automations that you've been meaning to build into these web- based routines and not have to keep your hardware on. Okay, so now that we've talked about routines, there are some other ways that you can actually go ahead and deploy automations, especially if they are more code-based, meaning they're more deterministic than nondeterministic. you only really want to go for a routine if you need that full agentic loop and you need like a legit clawed code. But sometimes you don't need clawed code. Sometimes you just need something that's really simple like a Python script that will execute a command or moving data from one platform to another on a web hook or something like that. So let's talk about other ways that you can deploy these sort of like clawed agents. All right, so remember how we talked about this AI systems pyramid a little bit earlier in this course. Where'd it go? Up here. And now that you understand routines, you know that that's basically us, you know, opening up Claude and actually sending it a prompt here and we get that full agentic loop inside of Claude code because we're using the harness and we're using the model because it can use our skills and our files and look through everything. So routines are insanely powerful and I love them. But the thing is you don't always need a routine because once again you want to have it as simple as possible. And routines are basically a mix of the chatbot but also the agent because but realistically what happens is we have this agentic loop where we don't exactly know what it's going to do and why. So if we can make these routines a little bit more deterministic then we probably would like to and on top of the fact that if you're doing cloud routines you have a limited amount of how many can go off per day. So it's always nice to try to find only use these routines when you actually do need them. So, let me talk about a real quick example of let's say we wanted to do a daily AI briefing. What would that look like? Well, we probably would have something like this. The trigger would be maybe 6 a.m. And then from there, what we would do is we would do research. So, research on like the AI space. Now, maybe we have multiple sources of research. Maybe we want to do, you know, X and we also want to research um just in general like Tavly. So, maybe there's two different sources, you know, just the web, maybe even LinkedIn. And then what we would do is we'd maybe consolidate that research and we'd send that into an AI model who would like write the report, right? So this would write the AI briefing and then from there what would happen is we would want to get that sent to us somehow. So send to user. This is basically the order of operations that we need for this briefing. In the morning wake up do the research write the brief send a user. So because this is such a linear predictable process, even though let me just actually um I mean this is like the main AI step, right? So I'll just call kind of call this blue. Even though there's AI inside of it, this is still very much a linear predictable workflow. So there's no need to go for a routine here where we would have, you know, an AI agent step and the agent would be responsible for doing all of the research and the writing and the sending. Right? This is what this would look like more as an agent because it has access to all these tools and it can do things in different orders where like this would totally work as a morning AI briefing, but it's not as efficient and we could definitely do it like this, right? Like we're not really going to be losing quality here. So, this is where we might want to do something like this and host it on modal or trigger.dev. Two tools that I do like to use. So, I'm going to show you guys a quick example of us building this out and it's going to be super simple and we're going to build this out in modal. So, real quick before we start doing this, if you don't have a modal account, go ahead and get signed up. modal.com. It's like I think you get five free bucks to start with and if you put in a credit card, you'll get an extra 25. So, it's super super cheap because it only actually charges you per run and it's pennies. So, you can see it's going to be pretty cheap. So, go to modal.com. You can sign up with the GitHub account that you created earlier if you built the websites out. And yeah, now we can actually build out this automation. So what I'm going to do here is I'm just going to start talking to our cloud code in a really simple way. I am looking to build an automation and we're going to ultimately have this deployed on modal. So it's going to be a Python script. All I want this to do is every morning at 6 a.m. Central time, I want this to fire. I want it to do research for me on the AI space. What I'm specifically looking for are any new AI news like announcements, any stories. So if the, you know, any companies have come out with a case study or if there was a a big failure or something like that or any acquisitions or IPOs, I also want to know if there's any new models or new tools or anything like that. So basically just a concise news briefing of what's going on in the AI space. And then I just want it to write that up in a nice way for me and shoot that over to me in ClickUp. So that is what the automation is supposed to do. I would like to use Opus 4.8 8 as the model that actually writes the email for us or the the daily brief. So with that information, let me know what questions you have. Let me know what API keys you're going to need for me. And then once we build this out, we'll go ahead and push that to modal, which I will also need your help with because I've never used it before. Okay, so that was my prompt. If you guys read this, you can understand exactly what I'm saying here, right? It's not technical at all. And now it's going to help us plan out this automation and then just actually go ahead and build it for us. I think the only thing that you guys might not have said without knowing is that it's going to be a Python script. But Claude would have done research on modal and it would have made sure that it built you the right type of file to send over to Modal. So here's what it's saying. It's going to need an anthropic API key because it's going to obviously need to call on Opus. It's going to need my ClickUp token so that it can send me um you know an actual message in ClickUp. And then it's going to need my Tavly key which I already have because it's going to use Tavi to do the research. And then it's going to need the modal account. So we'll need to give a modal token to authenticate. The first thing is how should the script gather the AI news each morning? We'll just say tavly plus opus. That works fine. How should the finished brief show up in ClickUp? I would like it to be a DM sent to the Nate Herk user in ClickUp. Now this is a permissioning thing. So we'll talk about that to make sure that we're more confident that it's going to be sent to only me in ClickUp. But I'll hit next for now. And then how long in detail should the brief be? I want it to be very very scannable. So we'll do this one. So, while all of that's happening, let's go ahead and start collecting these API keys. So, actually, instead of using an anthropic API key, let's use Open Router. And the reason why is because Open Router is way more flexible. So, if you haven't got an account here, go to open router.ai. And what you'll see here is that it has tons of different models, right? It has one API for all the models, higher availability, and it's just really cool. Basically, what that means is you can have a credit card in here and then you don't have to create an account for API usage, for anthropic, for Google, for OpenAI, for whatever one comes next because Open Router has basically all of the models. So, it's just nice for me to be able to stay organized and watch all of my activity in one spot rather than managing multiple different dashboards. So, when you get in Open Router, you're going to go to your credits. You're then in here going to go to your API keys, and then this is where you're going to create a new key. And we're going to call this our knowledge work demo. Here is where you can have a credit limit as far as price. You can have this expire. And I'm not going to touch any of that right now. I'm just going to go ahead and create this API key. And then, of course, it's going to give us one that we can go ahead and copy. So, I'm going to copy this API key. I'm going to go into Claude. We're going to open up ourv file. And then in here, what I'm going to do is I'm going to make this a little bigger so you guys can see better. I'm basically just going to add manually open router. So, I'm just going to do in all caps open router_appi key equals and I'm going to paste in that key. The next thing I'm going to do is in my ClickUp, I'm going to get the API key. So, I'm going to go into my settings and I have to just find somewhere right here, ClickUp API. And now I can copy this key and paste that in. So, pretty much whatever platform you need, it's always going to be in your settings. and you might have to look for developer settings or somewhere you'll have to find the API documentation or sorry the API key area but if your software has API documentation then you should be able to find your API key in the settings okay and this is pretty cool as I was adding those keys cloud code was actually seeing that and it started testing things out so I didn't even tell it by the way that I was going to switch from enthropic API to open router it just saw that and it used it so tavly is working open router's working and clickup I just added so hopefully it will test that in just a check or I might have to prompt it to but it looks like right now it's building the actual automation. So you can see it created this Python file which says AI daily brief a modal automation every morning central time. You gather fresh AI news with Tavi. You write a concise scannable brief with Opus via open router and then you deliver the brief to Nate as a ClickUp DM selfdm by default. Okay, so there we go. It says the code is written. Before we touch modal, let me prove that this works and show you the output quality. So I can run the research and then Opus will write and then we will skip the clickup send for now because it hasn't seen my token yet. But we'll just basically see the output that we will be getting inside of our ClickUp when this automation is ultimately done. And the other thing to think about here is what is our risk with this automation? That's a really important thing to think about is what is your risk? In this case, our risk is basically that it spends too much money, right? Our risk is that this somehow starts firing off a lot or it gets somehow stuck in a research loop with Tavi and we spend a lot of credits. So maybe we could mitigate that risk by scoping in those API keys so that they can only spend like a dollar a day. Another risk is that open router is down or tavly is down and in that case what do we do? Maybe we route from Tavly to like perplexity to do research if Tavi is down and maybe if open router is down then we would route to Enthropic. So, those are some of the other like what if edge case scenarios to be thinking about and to be protecting against. Anyways, here is what the brief would look like. This would be our chance to give feedback and iterate if we don't like how it's how it's formatted. But this one looks good. It gathered 30 stories. It dduped. It grouped and it's sourced. And we have it said it's written in my tone of voice as well. So, here is our daily brief for Friday, July 10th. Here are new models. So, GBD 5.6. Space X releases Grock 4.5. We're also going to get a clickable link with the actual source and an AI dominated H1 venture blah blah blah blah blah. Okay, cool. So now it's asking for my ClickUp token which I have pasted. So I'll say hey go ahead and test it out and then we'll set up modal. So awesome. So I've given you the ClickUp API key. Now one thing I noticed is in ClickUp I wasn't able to set up like a scoped API key. It seemed pretty general. So, I want you to help me figure out how do we make sure that this automation can only send to my ClickUp channel or my personal Nate Herk DM. I don't want it to ever be able to accidentally send into like the general channel or any public channels. It should only send to this one specific place. How can you prove that to me? And in this case, it's going to be pretty simple because the Python script is going to basically hardcode the endpoint to hit. We're not going to give modal the ability to change where it gets sent. So, we're going to send it to my ClickUp DM once and then it will never change because that step of the process is fully deterministic. This is where if we made this step non-deterministic and we let the agent choose where to send it, that's where you can get variability. But because we're writing an actual Python script, it's not going to change. So, boring is beautiful. Predictability is beautiful when it comes to self-firing automations. Okay, so it hardened up the code. Basically, what it did is it made sure that it's only able to send to this specific DM, which is perfect. It's blocking out all these public channels and blocking out all the other channel paths. And you can see here, this is the test delivery that it sent. This is a one-time test confirming the automation can post to this private DM. If you can read this, then delivery works. So, let's go ahead and get this pushed to modal. So, after all that, it wants us to run these four commands in our terminal, which we could easily just copy and paste in and it would not be difficult at all. But, I said, can't you just run all these for me? can't you just set everything up? And it said, "Yeah, mostly I can. I can set it all up, but you're still going to have to authenticate in." So, do you remember earlier when I was showing you how like sometimes it'll give you a link and you click on the link and then you log in to modal or to claude or to notion or whatever it is, and that's how it authenticates. That's what it needs to do. And it's going to basically kick that off. Now, we'll sign into modal and then claude code will come back here and say, "Okay, cool. I got your modal information. I got that modal token or cookie. And now I can set everything up for you." pretty much the same exact way that I use GitHub. You know, when I have Cloud Code doing things for me inside of GitHub, it can do everything. It can push commits, it can create repos, it can do everything. But I just needed to authenticate once and now Claude Code can do everything. So, as you saw, this page opened. I just have to authorize Cloud Code to use my workspace right here. And then it says, "Your client has been granted an API token and ready to use modal." And now Claude, if we switch back in here, is going to be able to actually make all that stuff. Okay, look at this. In my modal, we can now see that we have this AI news brief and it just got taken away because Claude is right now running a test. So, it tested it out and now maybe it found a problem or maybe it needs to refresh. But anyways, it looks like it's deploying it again. So, I'll go back into modal. We'll hit a refresh. We see if we get anything. This should pop up in a sec. But also, what I realized is I got a ClickUp message. So, this ClickUp message just came in 11:42. And this was our daily brief. So we saw the new models, we saw new tools, we see Google photo ads video remix, we got meta rolls out AI room visualization, we got funding, we have business adoption, and we have some failures and controversies. So this is an example output. If we wanted to change this, we easily could instruct Cloud Code to change up the script a little bit, but right now I'm happy with that. And it looks like in here, we just got our AI news brief back. Let's see what Claude is saying. It says that it's live. It says that this is the app name, and this is the link. Every day at 6:00 a.m. Central, it will go ahead and write that. And take a look at this. So as far as managing it later on modal, we can see everything. We can see the runs, the logs, and the errors. We can trigger it on demand. And we can also rotate keys. So what happens is remember how our secret keys, our API keys live inside of thev file in this project. Modal needed to access those somehow. And what it does is it stores those in modal as secrets right here. AI news brief secrets. You can see that it's able to run this script and that's how it's able to grab different environment variables that we need and it stores them securely in here. Right here, if I click on edit, you can see we have the ClickUp token. Here's the token. Open router and Tavi. All of those tokens are in here. And if we needed to change them, we could change them. And if we wanted to add more, we could add more. So that's where modal stores our secrets. Now, as far as the app, let's take a look in here. So you can see next run is in 18 hours, which would be 6:00 a.m. tomorrow morning. But we could also hit run now. And when I click run now, it schedules the run right now. That doesn't mess with any of the scheduled ones. But what I wanted to show you guys is what it looks like when something is actually running and how we are able to use modal here for our sort of like visibility. And that's really really important observability and visibility. So right now you can see it's running. I'll click into it and we can see in the execution that we're actually seeing what it's doing in real time. So gathering news for Friday, July 10th, collected 30 unique stories, writing brief with Opus 4.8. You can look at the execution and you can look at the call graph if you really want to see like the timing of what's going on, which is pretty cool. But there you go. This one just finished up and it only took about 30.36 seconds. You can see if I go to the log, everything here was good. It delivered to ClickUp, sent brief to ClickUp to a private DM channel. If I open up ClickUp, you can see we once again just got another one, which is obviously very similar to the one that it just ran up here. But that's just proving that end to end this thing worked. And now we have logging available inside of Modal. in case anything ever fails, we can figure out why. We have the ID number for each of our executions. So, we can feed it back into cloud code later and say, "Hey, so these 10 runs were good, but if you look at run number 12 or you know, whatever number, this errored right here and figure out why and figure out what we can do to fix this so that this sort of error doesn't ever happen again. All right, so that is like a modal deployment that is cronbased." Cron just basically meaning it is on some sort of schedule. Now, what happens if we wanted to have something that's more web hook based? If you guys don't know what a web hook is, very simple concept. It's basically just think about it like a doorork knob. So, right now, what we're doing is we are scheduling off these automations based on time. So, 6 a.m. central, right? But what if we wanted to schedule an automation where I don't know, a good example would be every single time you get a new form submission. That would be a web hook trigger. Because if you're looking for an event, you can do something called polling, which is basically just constantly checking. It's basically just a loop of seeing, hey, is there a form? If yes, I will process it. If no, I will just wait 5 minutes and pull again or check again. And it's just this constant loop of polling every 5 minutes or every 10 minutes or whatever interval you decide to pull. But instead of polling, what you can do is you can set up a web hook, which means basically if you think about it like a door, I did I say earlier doororknob? I did not mean to say doorork knob. I meant to say doorbell. If you think about it like a door, rather than saying, "Oh, I wonder if there's any guests at my door. I'm going to go open it every 10 minutes. And rather than checking every 10 minutes, you could instead just say, "Oh, okay. I'm going to put this doorbell here so that whenever someone comes, they ring the doorbell and then I know to go open the door." So that's basically all a web hook is. It's one system sending a request to another system that tells it, "Hey, it's your turn to do some sort of work." So in the case of a form submission, as soon as someone fills out a form and hits the button submit, that should send an API call to our web hook. So, let me show you a super super simple example of what that could look like. So, I'm going to go ahead and do a session handoff here because I want it to sort of have the context of what we just did with modal, but I want to have a fresh context window because right now we are at 133. So, just a good place to sort of clear it out and restart because we're starting a new build. If we were still editing on this one and improving this one, I wouldn't have done this. But because we're starting a completely different like project, I'm going to go ahead and get a fresh session to work off of. Okay, so I'm going to copy this. I'm going to clear out this context, paste in the handoff message, and then I'll show you guys what we're about to do. Okay, so now I'm going to do a /goal just to make this more fun. And here's what I'm going to say. All right, so we just deployed a Python script to modal and that was a cronbased automation. Now what I'm trying to do is create a web hook based automation. So here's what I'm imagining. Create me an HTML document. Super super simple. That's a form submission. And when the user hits submit on that form, it's going to send that to our modal web hook. Now, all modal is going to do that Python script needs to read the form submission and then send me the business owner a notification saying, "Hey, you know, this user submitted a notification. Here is what his business does and here's what he's looking for." And then it will basically just send that to me once again in the exact same ClickUp private DM that the previous automation that we just built did. So you shouldn't really need anything new as far as API keys, but you do need to create me both of these deliverables, both of you know all these scripts and then go ahead and just do as much as you can here and then stop once you've tested and proven that this endtoend pipeline works and is deployed on modal. Okay, so that is my slash goal. I will basically just check in with you guys once this is done so I can show you what that web hook based automation looks like. All right, so this just finished up. That was insanely quick. If I go to my apps now, you can see that we have lead web hook as a separate app. You can see that there's two different functions. So this was a test submit which has zero calls and then we have the actual web function. If you look at this, you can see this isn't triggered on a schedule. If you guys remember in the other app, there was a timer right here and then there was a button to execute now. But the reason why that doesn't happen here is because when we send data over, it has to accept some sort of information, right? Because the form submitted data over to this web hook. So if I go back into the um cloud real quick, you can see that this is the form that it built. So if I put in my name, if I put in my email, and if I put in my business name, which is we'll just put in uppit. What does our business do? Sells shoes. And we're looking for AI implementation. And if I hit submit, let's see if this HTML is working properly. This should trigger a request to modal. So, thanks, your submission was received. If I go back in here, we see that we just got a submission to come through. We got an options and we got a post. So, if I click on this one, we should see sent lead notification to ClickUp. We can go to execution. We can see we got all of this. Now, let's make sure that it's actually capturing the right information. Boom. I go over to my ClickUp and we can see new lead Nate. We have the contact as nateest.com. Their business sells shoes and they're looking for AI implementation. Now, one thing I want you guys to take note of here, this has zero AI involved. It's literally as simple as whatever data is submitted in here. The modal script or the Python script uses a template and basically just fills out the information exactly as the user typed it. If this was AI, it probably would have fixed my typo. I didn't even realize that I put two A's in there and it probably would have just like formatted this a little bit different. But that would be a waste. Build the simplest solution that you actually need for the problem. And in this case, the problem was we want form submissions to instantly come to our ClickUp. And this is getting the job done. I don't really need AI here at all. All that would do is it would add a little bit of risk and it would increase our cost. So great example of a situation where a simple modal script, this took probably four minutes in total. And now anytime someone would submit a form on our website, we would instantly get their submission. All right. So now that we understand how to deploy stuff, I want to talk about another way that you can actually use your own cloud stuff. Because what happens is as we're building out these folders and files and skills and all these connections, it's really valuable. And I don't know about you guys, but I get in this situation where sometimes I get anxious about like leaving my house or not not leaving my house. That makes me sound like I'm a freak. I mean, like I get worried about how much work I'll be able to do if I'm maybe like on a vacation or if I'm away from my PC setup cuz I like my monitors, I like my standing desk, I like all this, right? But what we can do is we can use a thing called remote control, which basically lets us use our phones to actually continue to work on our sessions. And what I love about remote control is because it's it's so so easy where I can go down to the gym and before I do, I'll just start a remote control. So, as I'm, you know, working out, I can keep sending off prompts and I can keep building stuff. or if I know I'm going to go on a walk or if I know I'm going to go to lunch or even if I know that I'm going to be away from my home setup for a few days, obviously I bring my laptop and I'll still have my AIOS on my laptop, but I can still start a session from my phone and just check in on things. So, remote control, super cool and it's super easy because all you have to do here is you're on a certain account, right? So, pretend this is, you know, nateis.com is my email that I have this account on on my phone on the Claude app. I would also just need to be signed in nateis.com. And then let's say you see this session, right? This was our agent team debate session. All I have to do is come in here and do a slash remote control. And when I shoot that off, that basically just like exposes this session. It is local, but it exposes it for my phone to be able to control it. So, I'm going to open up my phone here and I'm going to go into the clawed app on my phone. Now, when I'm in here, what I can do is I can go to the code section. And now, you can see I have an idle session. So, you guys probably can't see this too well, but if I hold this up to the camera, this is our session, right? So you can see here it says like the verdict, the stats table, the round table. If you look really hard, you can actually see that's exactly what it says right here. The verdict, the stats table. Anyways, let me just prove it to you by shooting off a prompt. So on my phone, I'm saying, "Hi, this is from Nate's phone." And I will hit enter. And now you see that this is going to come through on our laptop right here, or sorry, not laptop, on the desktop. And it's processing that message. So it saw, hi, this is from Nate's phone, blah blah blah. And I'm getting all of this response on my phone as well. So basically the point is we now have two different ways to control this session. I can do it from my phone and I can also do it from right here. So what also is cool is I can come in here and I can do a slashclear. So I sent slash clear from my phone and what's going to happen is it's still able to recognize that that was a slash command and you can still have all that full functionality of what you typically are doing when you are driving this from your computer. Okay, you know what? That's actually really weird, but I'm glad that we found this out. So, I'm not sure if this is a bug because I have to relaunch or, you know, the desktop app is always being improved on, but both of my slashclear commands came through as no content, which is very strange because I do this a lot from my VS Code terminal and it works. So, that's just another quick example of some of the tiny tiny little things where the VS Code terminal gets you the full functionality. And for some reason, that didn't work when I did this here, but that does work when I'm using the terminal. But anyways, that is remote control. Like I said, it's super handy if you know you're just going to be stepping out for a bit, but you still want to keep being able to check in on something and keep working on something. So hopefully you guys are able to find some good use cases for that. Okay, so that was remote control. Now, token management, such a big conversation, right? It's always going to be important even when we get into the future and models are getting cheaper potentially and you're able to run them locally, but token management is so so important because not only from a cost perspective, but from a performance perspective. We all know about context rot and we all know about things like confusion or bloating when it comes to the context window of your AI agents. So, we're going to spend some time here talking about tokens, what they really are, how they work, how Claude works with them, and how you can actually use these little tricks and use these things and keep them in mind to maximize your sessions and your tokens. In the past week or so, so many people have been complaining about hitting their claude code limit insanely fast. claims like one prompt that is about 1% of the limit is now around 10%. You could go through X and find tons and tons of threads about this topic. Even on a $200 per month plan, people are reaching the session limit way too fast. And then we got this post from an anthropic employee that basically said that they are working on a little change with peak hours and off peak hours. But even after that, some people were saying they were still hitting it really quick even during off- peak hours. So anyways, I've been playing around a ton, trying different things, doing research, and I have 18 token management hacks for you guys that I've organized from tier one all the way up to tier three, so they get more advanced as we go. I'm very confident that by the end of this video, you will feel like your Claude code usage has doubled, tripled, maybe even 5xed. So, let's not waste any time and just get straight into the video. So, as I've been optimizing my own token management, I think that what's really important to realize first is how tokens actually work. Because once you realize how Claude uses tokens, it makes it very clear how you should actually reverse engineer the way that you work in order to use less tokens. So a token is the smallest unit of text that an AI model reads and charges you for. It's roughly one token is one word, but that's not explicitly true. Kind of just a good baseline. So every time that you send a message, Claude rereads the entire conversation from the beginning. And all of those are tokens that it's charging you for. So, message one, it will read it, then it will read its reply, and then message two, and then the reply all the way up to your latest prompt. And it does that every single time. And I think that alone is a huge light bulb moment for a lot of people. This means as you're having a conversation with Claude, your cost is compounding, not just adding, it's exponentially growing. Meaning, message one might cost 500 tokens, message 30 costs 15,000 because it's rereading everything before it. One developer actually tracked a 100 plus message chat and found that 98.5% of all the tokens were just spent rereading the old chat history in the session. Like that's a huge waste. Now yes, the argument has to be made that well it needs the context and it needs to understand what we're doing. But still 98.5% is crazy. So take a quick look at this graphic here. Along the x-axis we have message number and as it increases you can see that we have our per message cost and our cumulative tokens increasing. But it's not linear. It's basically each message is rereading all of the past ones and it has to count that in. So message one could be 500, message 30 could be 15,500 which is 31 times more. And then after 30 messages you might already be at almost a quarter million cumulative tokens. Now on top of all of your own messages, Claude will also reload your cloud.MD, your MCP servers, your system prompts, your skills, your files on every single turn. And this is invisible overhead, but it is constantly dripping into your context and your tokens. And a really important thing to realize is that bloated context doesn't just cost you more money, but it also produces worse output. So you're paying more and you're getting less. There's this phenomenon called loss in the middle, which basically says that models are paying the most attention in the beginning of your session and kind of at the end. So all that stuff in the middle of your session, kind of in this dip is getting ignored. All right, so now that we kind of understand a little bit more about how cloud code works and how tokens work, let's move into the hacks. We're going to start here with tier one hacks. These are the ones that are going to be super easy to implement and everyone should be able to understand. So, we've got nine of these. Number one is to start fresh conversations. Use slashclear between unrelated tasks. Don't carry context about topic A into a conversation about topic B. So, every single message in a long chat is exponentially more expensive than the same message in a fresh chat. So, this one habit is the number one thing that extends your session life. And it's pretty obvious based on what we just talked about. So, that's why this was number one. Okay, number two is to disconnect MCP servers. Every single connected MCP server loads all of its tool definitions into your context on every message. This is another source of completely invisible tokens that might just be eating up and eating away. So, one server alone might be something like 18,000 tokens per message. So, run MCP at the start of each session and disconnect the ones that you don't need. And better yet, if you're able to find CLIs for something, so for example, rather than having the Google Workspace or Google Calendar MCP server, which eats a lot of tokens, just use the Google Workspace CLI. It's faster, it's cheaper, and I think the future is moving towards having our agents use CLIs rather than MCPs. All right, number three, batch prompts into one message. Three separate messages cost three times what one combined message costs because of the way the tokens work, right? Instead of summarize this as one message and then now extract the issues, now suggest a fix, send it all in one prompt. If clog gets something slightly wrong, edit your original message and regenerate instead of sending a full follow-up correction. Follow-ups stack onto history permanently while edits replace the bad exchange entirely. Now, I will say there is an argument to be made here that potentially doing it this way where you're doing task one, task two, then task three might actually be better output quality. I think it depends on the actual use case. Basically, the idea would be if you can give AI one specific task at a time, it's going to do better because it's more specialized and it's more focused. But this is definitely something that you should be aware of. Okay, number four is to use plan mode before any real task. This lets Claude map out the approach, ask you the right questions, and it prevents the single biggest source of token waste, which is just having Claude go down the wrong path, writing code, and then basically everything that it just did, you have to basically like scrap and redo. It's just a huge waste of time and tokens. So, you can add something like this to your cloudmd. Do not make any changes until you have 95% confidence in what you need to build. Ask me follow-up questions until you reach that confidence level. This is something that I'm putting into all of my cloudmds when I am having it help me build things. Number five, we have run/context and /cost. /context shows you exactly what's eating your tokens right now. So, your conversation history, your MCP overhead, loaded files, stuff like that. And /cost shows you your actual token usage and estimated spend for that current session. Most people have no idea where their tokens are going. And these two commands make the invisible visible because if you don't actually know that you're bleeding because of MCPS, then how would you be able to fix that? So, when you run /context, this is what it will look like. It'll basically give you a screenshot of how many tokens you're at, what is the cap, and it will estimate based on the different categories. And what I did here is this was ran in a completely fresh session, no chats. So, what that tells me is, okay, before I even talk to Claude, I'm already down 51,000 tokens because of things like the system prompt, the system tools, my custom agents, my skills, memory files, and here I've actually cleared out all the MCPS, so there wasn't anything in there, but those can, like I said, completely blow up your tokens right from the get- go. Okay, number six is to set up a status line. This kind of goes handinhand with having more visibility. You only actually see this in your terminal, though, so you will have to do it there. Um, and it basically lets you see what's going on. So, right here, you can see in my terminal, I've got this set up so that I can see the model I'm using. I can see a visual kind of progress bar of my usage. And then I can see uh 5% of my whole 1 million context window. And I can see 52,000 tokens out of a,000,000, which is a million. And just to clarify, this isn't my session, like my 5 hour session. This is basically just indicating that I'm 5% of the way or 52K out of a,000K. So all you have to do is include code in the terminal do /st status line and explain that you want to replicate this setup. Number seven is just super simple but keep your dashboard open. Same thing with visibility. You might run into issues with your limit and just get hit out of nowhere. But if you have it pulled up next to you or you have it ready so that you can switch into that tab and you know check every 20 40 minutes then you're going to be able to pace yourself a little bit better. You could even set up a automation to basically check in on it every 30 minutes and send you like a text or a Slack message and say, "Hey, by the way, you're getting near your usage." All right, so number eight, we have be smart with pasting. Before you drop a document or a file or something large, just ask yourself, does Claude need to read this whole thing? Sometimes it does. Sometimes it needs that full context, but sometimes it just needs one section or one page. So if the bug is in one function, then paste just that function. or if it just needs the context of one little paragraph, just paste that. Claude needs to be precise about what it reads, but you also need to be precise about what you feed it. And number nine, our last tier one hack is to actually watch Claude code work. Don't just fire off a prompt and walk away or switch tabs. Watch what Claude is doing, especially on longer tasks. And this is because if you actually sit and watch it, sometimes you'll realize it's going down the wrong path. Sometimes it gets stuck in its own loops, rereads the same files, things like that. So, if it's doing that, you might as well just stop it right there. Kind of the same idea as plan mode. Why would you let it go down the wrong path, waste all your tokens, and then just have to scrap it all in a bad loop? 80% of the tokens are being used, producing zero value. So, if you're able to just watch your session run until you know it's going down the right path, it could save you thousands of tokens. All right, let's kick it up a little bit. Let's move into our tier 2 hacks. And for these ones, we have five of them. So, number one is to keep your claw.md file lean. Place it in your project route, whether that is globally or in in local project. Claude auto reads it at the start of every single chat as system context. So keep it under 200 lines. Include things like your text stack, your coding conventions, your build commands, the 95% confidence rule, only the most important things. And you need to treat this like an index route to where more data lives. And it's a complete mindset shift. This file basically just tells Cloud Code where is everything that it needs and what to do every single time. So it can point to files that are huge, but that way it just says, "Okay, I don't need this right now, but if I do need this, I know exactly where to look." And because it knows exactly where to look, it's not going to waste time or tokens searching through and reading other files. It's just able to grab it right there by the file name. And the reason I say this is a mindset shift because you should be doing this with other things, not just your cloudmd, with your skills or with your um, you know, master reference guide sheets. I saw someone talking about how they created an index that's super super lean and it shows cloud code exactly where to go in the cloud code documentation. So if it needs help with something related to cloud code, it doesn't have to search through the whole database. It can just say, "Okay, here's my index file. I know exactly which URL to look up at." Super simple. You want to keep this lean and trim it all the time. It's always a work in progress because every single chat, not just like your session, every single message, CloudMD gets read. So if your CloudMD file is a thousand lines, every single time you shoot off a message, even if you just say hi, the whole thing's going to get read. Okay. Number two here is to be surgical with file references. Don't just say something like here's my whole repo, go find the bug. Say something more like check the verify user function inside the off.js file. Or you can also use at file name to point at specific files instead of once again letting claude explore freely. The whole idea of being specific and routing. All right. So number three, I'm saying to compact at around 60% capacity. Autocompact triggers at like 95% by which point your context is already pretty degraded. So run /context to check your capacity percentage or you should have the status line set up and at about 60% just run the slash compact with specific instructions on what it should actually be preserving. After three to four compacts in a row the quality does start to degrade. So at that point once you've done three or four just get a session summary/clear give the session summary back and then keep going. All right so number four short breaks are actually costing you. Cloud code uses prompt chaining to avoid reprocessing unchanged context, but the cache has a fiveminute timeout. So if you step away and you come back and it's been longer than 5 minutes, your next message reprocesses everything from scratch at full cost. And that is why some people feel like their usage just randomly spikes if they might have, you know, stepped away and came back. So if you're going to do that, just consider doing a /compact or a sl before you step away. All right, number five, command output bloat. When Claude runs shell commands, the full output enters your context window. So if you have a command that it comes back with 200 commits or you know just tons and tons of data, then all of that is tokens that gets sent to your model. So really the takeaway here is to be intentional about what you let Claude run. If you know in a certain project that it doesn't need to use certain commands, then you can go ahead and in that project deny those permissions. And this is another one that seems like it's invisible because when it runs like a bash or, you know, certain commands, it basically just has like one line and you don't actually see all the tokens that it has, you know, sent there. All right, so I'm sitting here editing this video and there's just one more thing that I wanted to get off my chest and it's basically about hitting your limit. And you know, the goal of this video and your goal should be to optimize so that you don't hit your limit. But I don't think that you should associate hitting your limit with like it shouldn't be a negative connotation because ultimately if you're doing a lot of these hacks and you are not just like being wasteful with tokens then hitting your limit is actually a good thing if you think about it because it means that you are using this tool so much and I think that's what you want to be. I think you want to be a power user of this tool to the point where it's like got to wait again and you know waiting sucks but people that are using it so much are going to be so much more productive and so much farther ahead than people who are never hitting their limits you know not make not getting their their money's worth and not truly getting the leverage that you are now getting. So anyways, quick little raw rant there, but I think it's an important mindset shift to have. You know, just something to think about. All right, so we're moving on to tier three now. I hope you guys feel like you already have a lot of things that you want to implement and these ones are getting a little crazier as well. So we've got four of these here and I've got a few bonus ones also, but number one is to pick the right model. So sonnet for your default most coding work, haiku for sub aents, formatting, simple tasks, opus for deep architectural planning, and only when sonnet wasn't enough. Try to keep this under 20% of usage or unless you just really really need it for that project. Now, a little tip here is when you have a huge code base and you want to do certain things like maybe a review, then try bringing in codecs. There is an official plugin now and I made a video about this. I'll tag that right up here. But you could basically have, you know, Opus and Sonnet working together to build you, you know, a project or a codebase and then you could just bring in codeex to actually review everything and that way you're saving yourself on the clawed tokens. The next one, number two here, is the cost of sub agents. Agent workflows use roughly seven to 10 times more tokens than a standard single agent session. Now, why is that? Because they wake up with their own full context and it's a separate instance. So, they basically have to reload everything when you start up the new session. All of those files, all of the system tools, like everything like that. Now, what you can do though, which is helpful, is to delegate to sub agents for one-off tasks, especially if you want that one-off task to use Haiku. So maybe you need to process a lot of information or maybe you need to do a ton of research and get just like a summary back. Now yes, tokens are still tokens no matter what at the end of the day, but if you can make 80% of your tokens a cheaper model rather than 80% of your tokens an expensive model, then you're going to be saving money. And then of course agent teams are cool. Um sometimes I really do actually like them and it helps me get more higher quality outputs, but they're very very expensive. So try to use them very sparingly. All right, so number three is to understand peak hours. So we just talked about at the beginning how they've adjusted how fast your 5 hour session window drains based on demand during the peak hours, which are 8:00 a.m. to 2:00 p.m. Eastern time on weekdays. But off peak, this is when your usage is kind of either normal or it lasts a little longer. And these are afternoons, evenings, weekends. So, if you actually think about this strategically, maybe you want to make sure that you're running big refactors or multi- aent sessions or big projects during off- peak hours only. Otherwise, you're going to, you know, drain right through that peak session. And on top of this, we'll call this a little hack 3.5, which is the one I kind of alluded to earlier when I said, hey, just keep open your clot account so you can see your usage at all times. If you're near a reset and you have room left in your allocation, then go heavy. Try to hit that usage limit before it resets. Get your money's worth. Let your agents go loose at that point. And on the other side, if you're getting near your limit, but you still have lots of time, then step away. This is your time to take a break, take a walk, make some lunch, come back with a full budget instead of burning the last 5% on something small and getting stuck mid task and having to just kind of, you know, lose that flow state that you might have been in. Okay. Number four, your systems constitution, which is claw.md. This should contain stable decisions, architecture rules, and progress summaries. Think of it like the source of truth that makes every prompt shorter and shorter. Save decisions, not conversations. Every architectural call that you store there is a paragraph that you never have to type again. So, this builds on top of the way that you were thinking about it back in tier 1. You can add rules in there that basically tell it, "Hey, I want you to help me make sure I'm being smart about tokens. Use sub agents for any exploration or research. If a task needs three plus files or multi-file analysis, spawn a sub aent and only return summarized insights. Spawn that sub aent in Haiku. And here's a little prompt that I have at the bottom of mycloud.mmd. And I will say before I read this out, you have to be careful because when you make a file like this, um, kind of self-learning or self-evolving, you have to check on it frequently because you don't want it to accidentally get too bloated. But here I said applied learning. When something fails repeatedly, when Nate has to reexplain, or when a workaround is found for a platform tool or limitation, add a oneline bullet here. Keep each bullet under 15 words. No explanations. Only add things that will save time in future sessions. And then it's got some bullets. Now, I'm not saying this is the most optimal prompt, but I think this sort of system of having your Claudetm MD actually learn and continuously think about how it can save you time and tokens is a good idea to play with. All right, so I know that we just went through a ton of stuff. This whole slide deck will be available for download for free in my free school community. The link for that will be down in the description. But right now, what you should go do are these things. Go run/context, see what it looks like. Go to some of your active sessions. Run/cost status line. Make sure it's showing your model, your context percentage, and your token count. Make sure you pull up your clog usage dashboard so you can see your remaining allocation and what time it resets. Disconnect unused MCP servers. Start complex tasks in plan mode. Use/clear when you're switching to an unrelated task. Manually compact at 60% context. Batch your multi-step instructions into single messages. And schedule heavy sessions for off- peak hours. and really just be mindful about the actual timing. So, I wanted to kind of leave you guys with one maybe two messages. The first thing is just the idea that there is a balance between quality and cost. And so, that's kind of a game that you have to play a little bit. And sometimes you do have to go for the higher quality, which ultimately is going to cost you more money. And that's just the way it works. But the other thing is just to keep it simple and think about what we talked about at the beginning of this video, how tokens actually work, how Claude Code actually charges you. Most people don't need a bigger plan. they need to stop resending their entire conversation history 30 times when you could just send it, you know, five times. It's not a limits problem. It's a context hygiene problem. So, look at this. On this day, I saved 91 million tokens because of cache read. And in the past week, I've saved over 300 million tokens because of it. Now, don't freak out. This isn't anything that you have to go change. This is happening automatically if you are using Claude Code or Claude. And I know that the concept of prompt caching might seem a little bit overwhelming, but today I'm going to make it as simple as possible and only really tell you what you need to know in order to make sure that you are saving your session limits and saving tokens. I'll also give you guys this entire token dashboard for free so you can actually start tracking your tokens a little bit better. Anyways, so let's talk about prompt caching, why your sessions burn out, and how to stop it. So what does caching actually cost you? Well, cached tokens only cost you 10% of normal input. So all the tokens that are getting cached are saving you a ton of money. So, if we go back to this example, on this day when I had 91 million tokens cached, that costed me only as if I was processing about 9 million of those tokens. The cache window on a cloud subscription is an hour. Meaning, if you're working with cloud code and you don't touch it for an hour and then you send another message, everything in that session gets uncashed. So, if you leave a session sitting for an hour or longer, then you're going to pay more for it. And if you're using Claude via API or sub agents, then the TTL or the time to live is only 5 minutes. You can change that, but it's just a little bit more expensive. You can bump it up to an hour if you want. But for claude code inside of your terminal or your extension, whatever it is, that's an hour. And now here's a quote from Thoric from Enthropic. He said that we actually run alerts on our prompt cache hit rate and declare SUVs if they're too low. So basically them saying, "We take this stuff really, really seriously and if we see that the hit rate isn't very high for users cloud code caching, then we do something about it immediately." And that's very nice of them. But also, of course, it benefits themselves because with a high cash hit rate, cloud code feels faster. Their serving cost is lower. Subscription limits feel more generous, you know, because you're using less. And long coding sessions stay practical. And then if you have low cash hit rate, this is what happens. And obviously, it's just a lose-lose for everybody. And that's why I said like prompt caching can get very, very complex. And if you want to check out more, then I'll link this article right here, which Thor really goes into some depth here. But if you read this, at least when I did, I was like, "Okay, this is a little bit overwhelming." I have a feeling I don't actually need to know all of this, but I do need to know at least a little bit, at least, you know, the 8020 of prompt caching so that I can get the most out of my session limits. And that's what I'm going to break down today. So, let's take a look at an example of how this actually grows. So, by default, when you shoot off a message to Claude, there's going to be some information that needs to be cached right away. And actually, let me just switch back to one of Thor's graphics real quick. You can see here that we have the base system instructions get globally cached. We have tools like read, write, bash, grap, glob globally cached. We have per memory or sorry per project things like cloud.mmd in memory and that gets cached per project. We've got session state and then we have user messages which grow each turn. So now that we take this into context and we flip back over here, this is what it looks like. This is an example where we have four turns. So on turn one there's no cache. Basically we're matching on a prefix. So don't really have to worry about what that means, but I might mention that later. So anyways, on turn one, there's nothing, right? We're opening up a fresh session. We load in the system prompt, the project context, and we shoot off our first message. And all of this is kind of in this like brown highlight border, which means that this is new, and it has to be fully processed, and it's being written to the cache here. So before I continue down this graphic in this dashboard, you can see that we have the difference between cache create and cache read. So on these days you can see what are my input tokens, my output tokens and my cash create. And then over here you can see my daily cash reads. And just a quick explanation a cash create is writing something into cache for the first time. It's a one-time cost and it pays off the next turn unless of course everything gets uncashed. And the cash read is tokens that claude reused from a cache like your claw.mmd or some of the files or some of the global system instructions. And these are the things that are 10 times cheaper than fresh input. So anyways, on turn two, given that we're within that 1 hour TTL window, everything here is already in context. So it's cached and then all that Claude actually has to process for the first time is reply one and message two and it caches that. So then down here in turn three, all of that's cached and we are bumping up a reply and a message and those are the things that only get processed each time. But if we waited an hour and then we sent another message or if we change the system prompt then everything from the very beginning has to get fully reached. So imagine if you were on message like you know 16 and you're way way way over here on the right and you change the system prompt or you wait an hour then everything getting reached is going to be a pretty expensive move that you just made. So anyways once again we have the system layer, the project layer and the conversation layer. The system layer has instructions, tool definitions, output style, and here's where it might break. The project level or the project layer has cloudmd, memory, and rules, and then here's when that might break. And then we have, of course, the conversation, which is just like the replies and the messages, which gets reached every time, but that's how it should be. So, here's where there's been some confusion among the community. So, how long does the cache snapshot live, which is kind of called the TTL, the time to live. So on your cloud subscription, you have an hour by default because it uses your subscription. But if you go over that weekly limit and you are now playing in your extra usage territory where you are paying per token API, then by default that will be 5 minutes, which is very dangerous. If you're managing multiple sessions and you're constantly reaching everything because five minutes is passing, you got to be careful about that. And people were kind of suspicious. I don't know if you remember like a month or so ago when everyone was complaining about their Clawude uh subscriptions how quick they were eating it up. People thought maybe that they switched the cash TTL from an hour to 5 minutes without like saying anything to anybody. It turns out they didn't. So it is an hour but that's just like you know there was a lot of confusion around that and I get why because honestly it's not super clear. Like if you're on an API, you have 5 minutes by default, but you can increase the cost and you can do an hour and then your sub agents on any plan are going to be 5 minutes. And for some reason, all of this is documented about cloud code and the API, which are two very different things. But the claw.ai like on the web, we don't know exactly how that works. At least I haven't found documentation on that exact. I'm assuming it's the same as your subscription, but I don't know 100% for for fact. Anyways, three habits that cover 95% of people. Don't pause too long. So if you've gone over an hour on a session, just hand it off to a new session. Obviously, start fresh when you switch tasks. So do a slash compact, which will break the cache, or do a slash clear. Or you can also use my session handoff skill, which I will include as well for free. So both the token dashboard, GitHub repo, and the skill will be in my free school community. The link for that down in the description. But basically what that means is, let's say right here, I've got this project which helps me build this HTML file you guys are looking at. It's got 205,000 tokens in here. And if I come in here and just do a session handoff, this basically summarizes everything we've done, all the important files that we've built, all of the open decisions, exactly where to pick back up. And then I basically am able to just copy that summary, do a slash clear, and then keep going. And it feels like I haven't actually lost anything. So that has been basically my replacement for doing /compact. I've just enjoyed doing this better. And sometimes the compact takes a long time. This typically doesn't take anywhere over a minute. There you go. So that is my session handoff. I do a /copy and then I just go ahead and clear that. Paste it in, hit enter, and now I'm basically right back where I was. And then this last one is for if you're using Claude chat specifically. If you're going to be pasting big documents in there, you're probably better off doing a project because like I said, I don't know exactly how the caching works in Cloud Chat. But we do have some confidence in saying that projects, those files are cached a little bit differently and probably more optimized for storing a bunch of documents compared to just dropping them into your cloud chat. So keep it alive, keep it focused, and start fresh when you switch. Now, there's a few other things that were a little bit confusing to me as far as like what breaks the cache. So the first one is if you switch the model. So you know, if you're in here and you're talking to Claude, hello, hello, hello. And then you go in here and you do a /model and you actually switch the model, that's going to reach everything. Because if you remember earlier, I said it's prefix matching, which I'm not going to dive into right now. But if you switch the model, then you are switching essentially the prefix and it can't match on that same cache. So if you switch the model, you are reaching everything. Now I do want to apologize for something here because if you do model opus plan, which is something that I've shown before in like token hacks videos, this basically means it uses opus for plan mode and then it switches to sonnet for the execution. But if you do that, just keep in mind that's actually going to break the cache because you're switching model halfway through. So right here you can see each model has its own cache. Switching with model means the next request reads the entire conversation history with no cache hits even though the context is identical. The opus plan model setting resolves to opus during plan mode and sonnet during execution. So each plan toggle is a model switch and starts a fresh cache. So it's very interesting because typically the point of that is to save your session limit and I think ultimately long run it does but it is important to understand that doing that does reset the cache. Now what you can do is you can edit your cloud. MD and you can do that mid session because the edit actually doesn't apply until you restart that session. So the cache stays safe. And then of course the cloud.AI projects caching. It's not exactly documented but pretty confident that it does help to drop docs in projects rather than in the chat. But anyways this token dashboard like I said is very helpful to just be able to understand get a little bit more visibility into your tokens. This does track your tokens on a local device. So, if you switch over to a laptop, then your dashboard is going to look different than on your main like PC or whatever you use, but it's very, very simple. It is a GitHub repo. You will go to my free school community. The link is in the description. You'll click on classroom. You'll click on all YouTube resources, and then you'll be able to find it right in there. And once you get that GitHub repo, all you have to do is give the link to cloud code and say, "Hey, this is a token dashboard. Set this up on a local host." Boom. You've got it open. And it will pull in all of your past sessions. So, it's not like you're going to start fresh. As soon as you uh, you know, link in this repo, it will read your past files and it will pull in your tokens. And then, of course, I will also include that session handoff skill that I just mentioned to you guys. So, I know this one was super quick. Hopefully, this one was helpful, though. Um, it's just important. Like I said, when I hear about stuff like this, I love to understand it to the point where I know how to use it and I know what's going on under the hood. But truthfully, if I looked at some of these other articles, like how in-depth they go and how much nuance there is, most of the stuff right now, I just don't need to know because I'm not using the the API in this way super heavily. So, the reason I wanted to throw that out there is because it's important to stay updated and follow things, but just understand what do you really need to know at its core. Okay. So, we've covered a lot in this course and I hope that you guys are kind of proud of how far you've come since the beginning where maybe you didn't even know what cloud code was up at the front. We've covered a lot of fundamentals. We've gone over a lot of different kind of skills and different things that you need to be aware of. And now we're really getting into the part where it's time to build your AI operating system. You've already kind of been building up your context and your second brain and your knowledge, but now you need to have an operating system where you actually are able to leverage all of that knowledge and become 10 times more productive. And all of this is built on basically the four C's of building an AIOS as I like to call them. We have kind of these two, which is way more about the second brain element, context and connections. And then we have the capabilities and cadence. This is basically like the skills, the automations, the agents, and the routines and the deployments that actually make this thing work while you sleep. So, we've already spent multiple hours together in this course. So, I'm going to send you guys over to a different one. It's still completely free, and that is in my free school community. So, once you guys join this, or if you already have to grab all the skills and stuff, you're going to go to the classroom, and you're going to do the build your own AIOS course. It's a 2-hour course. It's going to walk you through the different mindsets around the AIOS and how you go from where you are right now to where you want to get to, which is probably something similar to me. But mine is still a work in progress. Every day, every week, every month, I'm adding so much stuff and I'm building it out. And this will never be a finished product. It's just going to be the way that I always work. And from there, if you guys enjoyed this course and you want to learn more and you want to connect with people who are building businesses or, you know, trying to get AI roles in companies, then definitely consider checking out our plus community. But anyways, that is going to do it for today. So, if you guys enjoyed, if you learned something new, please give it a like. It helps me out a ton. And I really, really appreciate you guys making it to the end of this course with me. And I hope to see you guys around in my communities or in future videos. Thanks so much, guys. Take care.
Jobs for this video
| Stage | Status | Attempts | Last error | Updated |
|---|---|---|---|---|
| summarize | done | 0 | — | 2026-07-13 03:40:56.382821+00:00 |
| transcript | done | 0 | — | 2026-07-13 03:39:49.172250+00:00 |
| transcript | dead | 4 | handler returned RETRY | 2026-07-13 02:53:31.217718+00:00 |
| metadata | done | 0 | — | 2026-07-11 22:02:21.423054+00:00 |