How to Actually Use Claude Code Dynamic Workflows

So, I just ran this cloud code dynamic workflow that analyzed all of my skills. You can see here that it spun up 41 Haiku scoring agents because I have 41 skills here. And then it's feeding all of that analysis into an opus synthesis agent. Now, because all of those agents were working in parallel, which is pretty cool. It didn't take that long, but it did take a ton of input tokens. It ate up basically 5 million input tokens, but there wasn't that much to output, so it wasn't super expensive. And I ended up with this HTML file where I could now look at all of my skills. It's ranked them worst to best and it's also given me feedback on how it could actually go and fix all of these skills if I wanted it to. It gave me patterns and it gave me other things to be careful of as I'm building more skills in the future. So, what I want to talk about today is what this feature is and how it works. I want to compare it to other things like skills and sub agents and agent teams because there's so many features in here that feel very similar and also kind of talking about the money aspect like did claude code make this feature just to incentivize people to burn more tokens and I also want to talk about some of the little hidden features and things that you really want to be careful about when you try out this new workflows feature. So don't want to waste any time let's just jump straight into today's video. So with the release of Claude Opus 4.8 8, we got dynamic workflows. And when I first started reading about this stuff, immediately I was a bit confused cuz I was like, well, we already have sub agents and we have agent teams and we have like this whole/goal feature. So, what really is the difference between a workflow and when do I want to actually use it? Especially after I've been seeing all this stuff about how much money it costs. And with my testing, I in one workflow prompt burned through half of my $200 a month subscription with just one prompt and it took a little over 30 minutes. So, if you're not being careful, you will obviously eat up your session limit very, very quick. So, the first thing that I wanted to start off this video by is talking about skills, sub agents, agent teams, and workflows because they're very different for different use cases, but they all sort of feel similar. So, a skill is a reusable recipe. And this is just when you're talking to your own claude, you can run these skills or you can have these skills be an automation. And you can also have a sub agent execute a skill or a sub agent within an agent team execute a skill. And of course you can have workflows execute these skills as well. So really what's changing here is how many agents are in the loop and if they can talk to each other or not. So with the sub agent sometimes these get executed or you know spun up automatically. Sometimes you ask one to you know get spun up and sometimes you build your own agent files that you invoke manually and these are basically just parallel agents that don't have the same context window as the main session. So keeps it clean. There's one of them unless you spin up multiple but they cannot talk to each other. They only talk back to the main working session that you are talking to. Agent teams are kind of like a small crew and these are also pretty expensive because they do talk to each other and they can share like a task list. They have their own context window but they talk to each other and that's really cool to have things like war rooms and councils and you know opportunities for agents to debate and work on an end goal together and they have individual roles and individual tools and individual like specializations. And then workflows are basically cloud code writing a script that runs these many agents. And it can be hundreds. It can be tons of different agents, but these are kind of more of a sub aent. They work alone. And then all of the results at the end get merged and sent back to the main claude workflow. Now, one separation here is who actually holds the plan. Because typically in cloud, if you're doing sub agents and stuff, the whole plan is right there with Claude. But what happens with a workflow is Claude basically creates a JavaScript file and that's what gets executed and that is the actual workflow that you know spins up and delegates all these different sort of agents. So it's very much still you describe the end goal and then claw just invokes this whole workflow idea to dynamically create the way that it's going to run. And what's cool about this is these workflows can be obviously saved and reran whenever you want to use them again. And so what I wanted to talk about here is the ladder of these different things because as you move up the ladder, you get more complexity and more functionality, but of course you start to bring on more risk and more money. So I love this little ladder diagram. And speaking of love, let's pause real quick for a message from today's sponsor. I wanted to take a quick moment to thank the sponsor of today's video, Lovable. Now I know that we can build websites and deploy those in a tool like Cloud Code, which I've shown on this channel, but hear me out. If you're just getting started in this AI world, a tool like Cloud Code has a lot of different things that are pretty confusing. And what Lovable does really well is makes everything super easy and minimizes the setup time. You can come into here with completely natural language and build an app or website or whatever you want. You can even power your app with a bunch of connectors that you already know and love. And you don't have to worry about handling API keys or file. You literally just connect with a one click of a button. And as you can see, it is so many different tools that you already know and love. like I just covered. I actually had all of my websites built out in Lovable and then we ended up moving them over to Cloud Code later once we were ready to scale and once we got a little bit more advanced, but I started out in Lovable and I iterated in Lovable because like I said, you basically just come in here, you have a chat with your agent and you get exactly what you want on this right-hand side and then thanks to Lovable Cloud, you just publish it right here. You don't have to sync it to GitHub, you don't have to sync it to something like Versell. You literally just click publish and then it's a live URL. And that's a massive advantage over something like Cloud Code, for example. I was also able to drop in a bunch of different Loom links and it actually just displayed them right here in my website for people to be able to click on, which I thought was pretty cool. And this site has obviously been deactivated because it was a very specific offer, but you also can get analytics about your site right in Lovable as well. And what else is really cool is you can connect Lovable to a bunch of different tools because it has an MCP server. So N you can connect it to there. You could also connect it to Claude, Jackbt, Cursor, Cloud Code, Codeex, OpenClaw, Hermes Agent, literally anything you can now connect it to because Lovable has an MCP server. So, if you want to play around with Lovable, you can get started for free. Just use the link in the description. And let's get back to the video. So, anyways, you kind of start here at the bottom where you're just talking to your main cloud code session and you're just asking and it's reasoning and maybe it's doing things like web fetch or an API call. And then when you start to have these reusable, you know, workflows, essentially reusable processes, that's where you create these skills and they get better and better over time. Now, sometimes you need to do things parallel to your main session and that's when you delegate stuff to sub agents. But then when you want to delegate stuff to sub agents, but you want them to talk to each other, then you have your agent teams. And then from there, I would say the last and final result because it's going to be I can't confidently say like more expensive than Agent Teams, but it's definitely up there with just like the way it could go rogue having a workflow. And the good news is you're not going to ever like accidentally invoke a workflow. It is going to confirm with you and it takes a lot to get them to actually run. So that's kind of the way that I think about moving up based on your use case. And honestly, one thing I want to say is for me because most of my cloud code usage is building automations and knowledge work rather than building like software and building apps, I don't think I'm going to use workflow that much. Like I just truly don't. I think there are some features in cloud code that are purely built for heavy code usage when you need tons and tons of things to be brought into the context doing a full sweep of a, you know, a PR or doing a full sweep of codebase and things like that. And so, for example, the the example that I alluded to earlier, which was me eating up like half of my $200 a month plan, was I asked to search through basically my whole desktop. It crawled all my local files, all of my repos, everything, and I was looking for an analysis, and I just wanted to see what it looked like to have a bunch of sub aents go crawling and looking and searching through this stuff, and that's where it ate up all my tokens. So anyways, just because you see a feature like this like workflows, it's good to understand the what, which is okay, what does it do and when would I use it in relation to something like an agent team or a skill, but it that doesn't always mean you need the how and that doesn't always mean that you need to use this thing every day or you're falling behind, right? It's just good to know what it does and more specifically if it solves a problem or a painoint that you actually have right now. And that's usually how I think about using stuff or not. So do the agents talk to each other? No. Right? right? They have got sublanes and they talk back to one result. Whereas an agent team is kind of like more of a group chat. It's it's legitimately a team which is super super cool. If you guys do want to see a full video where I broke down clawed agent teams and I'll tag that one right up here. So can a skill go inside a workflow? Yes, of course it can nest inside because the workflow is just basically spinning up a bunch of these different little sub aents and sub agents have access to read your skills and to use your skills. So you can do that. Of course, they can also use things like your MCP server connections or your API keys or whatever you've got stored in there that they you know that you want those sub agents to to use. The skill is kind of like the how. The workflow is like the how many and you know the width or the depth of execution. And now the one that I started to get confused about because I have been using slash goal a lot which I I plan to make a new video on /goal just on that topic but I've been using it a lot and so I started to think okay well when would I use slashgoal rather than workflow and so the thing that I started to think about there was depth versus width. So here's two visualizations that I thought explained it well. Goal is a loop where you're looking for kind of explicitly like does done equal true? And so the agent where you know in goal you can have sub agents get spun up don't get me wrong but let's just say we have one agent in a slashgoal it's going to take multiple turns and multiple passes until that end criteria has been met. So that's kind of like that loop where you could really have this thing run for 24 hours plus if you wanted. I've never done that but you could. And then workflow is more of a width play where you're getting a bunch of different sub aents doing different things or researching different things and then everything gets sort of synthesized together at the end which means you could have 50 plus agents horizontally working on stuff but they're not all checking against some sort of criteria of is done equal true. They're more so executing on on a plan that was established from the beginning and say hey this is what you do you do it and then you shoot that result off. So there's not like that endless loop of checking against a criteria. Now, what would be interesting is if you combine these two together and you had like maybe a workflow within a/goal or something like that, but obviously you'd want to be very very careful about that level of autonomy because it's very powerful, but obviously a great way to burn money. So some people out there are saying, hey, you know, they're just wanting you guys to use this workflow feature so you eat more tokens, which I don't think that's true, but that would be pretty funny because there is value here, right? It's just a matter of like, do you actually need this in your workflow or would that just be overkill? A lot of the times it probably would be overkill. So, the bill that you're going to get for your workflow is dependent on how big of a job you point this thing at. And each agent is a full clawed call, right? Each agent has its own window and has to read through its own context. And many of them get spun up. So, it can get very expensive. Now, most of your tokens here will probably be on the input like you saw with my example, which means that um it's not as expensive as the output tokens, but still it can get expensive. So, when you are shooting off a workflow, you want to be very careful about like, you know, how explicit you're being and how specific you're being with what you're actually looking for. Similar mindset when you're running a SL goal. Like, if you give it a very vague request, it might just loop for a long time because it doesn't actually know when done equals true. So bound the scope, name the deliverable and then all your sub aents can be put on haiku. Now there is a cool feature within the workflow thing which is a /deep research function which automatically invokes a workflow. It spins up a bunch of different agents to do parallel research. They vote on each claim and then you get a cited deep research report at the end. So that is a pretty cool feature. If you are doing a lot of research and maybe you're building your own deep research skills or whatever it is, definitely test out this one to see how that works as a workflow. And when you start to think about do you actually need it? Some stuff like this, right? If you're reviewing every file in a codebase or you've got a 400 file migration, you've got things where the the risk is high and you want as much compute and reasoning dedicated towards individual pieces as possible, that's when you'd maybe want to go for something like an agent team or a workflow. But if you're doing single edits or quick questions or you're just working towards a deliverable or you're doing general knowledge work, you probably don't need the workflow. So the question that I would ask is does this break into many pieces that can run individually of each other at the same time? If that's true, then go ahead and try out a workflow. So when I actually ran this in my cloud code, let me just real quick switch over to show you what the prompt looked like. Here I'm on the ultra code thing. This was the prompt that I ran for this workflow. I said, "Run a workflow that audits all of my cloud code skills in two places. My user level global skills and this project skills." And I said, I need you to grade it on clarity, front matter, pass, fail, trigger quality, and give me the single highest value fix. And I said, one final agent ranks every skill worst to best labels blah blah blah blah blah blah. And so after it did that, that's how I was able to get the output that I was looking for. And I also was able to have it have all of those workers being on haiku. Now, when I invoked that, what it did is it said, "Okay, can you let me run a dynamic workflow to do this?" And I had to explicitly say, "Yes, run it." Or you can see here that I could also view the raw script because as we know this is basically writing a script and then we just execute that script rather than having it be like all this you know sort of dynamic back and forth. And then while this is running you can do /workflows to actually view all of your open workflows if you wanted to stop them or view them. As you can see here I could see all 41 of these agents running and looking at different skills. I could see that they were all on Haiku. I could see how many tokens they had used, what tools and how long they had been running. And so what happens is this creates a JavaScript file. You know, you're able to keep it. It's in a workflows folder. You're able to run them again later, which is pretty cool. But what you may notice is that they might not go into your project immediately. They might sit somewhere else. So you can see here, I basically had to tell it to save it inside of this project in mycloud/workflows. If I open this up, I havecloud, I have workflows, and I have these two right here because by default, it was storing them somewhere else more global in my cloud code working directory. and I didn't want that. I wanted to see those right here inside of my Herk 2 operating system. So now, if I ever wanted to maybe do another skill audit or a different one I did was a cloud code feature ranking, I would just have to point it at that workflow and say, "Hey, run this again." And then the last thing I wanted to bring up here was the ultra code, which I just showed you guys cuz I thought it's it's very funny that they did this. When you go run/effort to look at your claw code um opus model effort level, you've obviously got low, medium, high, extra high, or max. But then you have ultra code which is going to be the smartest but the most expensive because what this does is it uses X high as the effort reasoning level. But every prompt I'm pretty sure is just going to be a workflow. That's kind of you know X high plus workflows. It's going to default here to using those workflows. So if you're on this mode it's going to bypass a lot of those permissions and it's just going to start orchestrating. So it's going to be very expensive. Now, besides that, when you're in here, if you do SLworkflows, that is how you can browse your history, right? I can see what is running right now as far as what's a dynamic workflow that's running. Or if you just go ahead and type workflow, you see that it highlights in rainbow. If I do an S, it's still there. And this is typically how you can request to do one on a turn. Now, you still want to be explicit. The best way that I found to invoke them is say, "Hey, I want you to set me up a dynamic workflow to do this." Because sometimes the word workflow just lives naturally in your speaking. So not every single time that you have this word does it mean it's going to automatically invoke a workflow. It'll just highlight up in rainbow colors which is pretty fun. So anyways, the whole thing in one slide. If you just have a quick thing, just ask cloud code. If it's a thing you repeat, use a skill. If you've got a messy side task, use a sub agent. If you need a small crew that talks together, use agent team. If you want something to keep going until an objective criteria has been met, use /goal. And if you want a giant parallel job, use the new dynamic workflows. Just be careful. And obviously MCPs, CLIs, API endpoints, all of that can be plugged into any of these here in order to actually connect data to, you know, your own systems. And I know that we just covered a ton of information, so I put all of this into a free resource guide that you guys can access for completely free. The link for that is down in the description. All you have to do is join the free group, like I said, and then in here, you'll click on classroom. You'll click on all YouTube resources and you can get everything I've ever shared. GitHub repo, skills, guides, all that kind of stuff. You can also come in here and take our free 7-day challenge or the free build your AI operating system course. So, I'd love to see you guys in this community. But that is going to do it for today's video. So, I hope that you guys enjoyed and you learned something new. If you did, please give it a like. It helps me out a ton. And as always, I appreciate you guys making it to the end of the video. And I will see you all in the next one. Thanks guys.