Dynamic workflows in Claude Code enable sub-agents to pass information directly to each other via code rather than through the main orchestrator, eliminating the 'sub-agent orchestration tax' where 90-95% of information is redundantly passed between agents. This feature uses JavaScript files with conditionals, loops, and schemas to create efficient multi-stage workflows that can run agents in parallel, stream results between stages, and manage token budgets, making complex multi-step tasks like code review, bug fixing, and research significantly more efficient.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
The New Claude Code Feature Going Viral Right NowAdded:
Okay, so about a year ago, Claude Code released sub agents and I was the first person to make a video about it. And now they made it even better by introducing something called dynamic workflows. And I think that this is my favorite feature of cloud code added so far. So I'll be going through everything to do with this feature and how you can make the most out of it to stay ahead of the curve.
Now, as a quick mention, there is a sale going on right now for my master cla which will be linked down below if you're interested. Okay, so I'll first go through what the problem is and then the solution so you can better appreciate it and understand how this fits into a wider picture. So by now you may have already been using your main session of cloud code as some kind of orchestrator whereby you may get the main session to tell a implementation sub aent to do an implementation then do a review with another sub aent of the implementation do a fix and then do another review again. Now the biggest problem with this is that we have a sub aent orchestration tax. So once sub agent A is completed then it will pass its results into the main orchestrator and then the main orchestrator will call in nova sub aent and it will pass like 90 95% of the same information into sub aent B and then that will continue from sub aent B into sub aent C. Now you can imagine that as we scale and we have like 5 10 20 sub aents inside of a single session then we have more tokens being passed around needlessly between the sub agents and the orchestrator and the orchestrator's context window is filling up as well over time and then it does a worse job at actually orchestrating too. So then the cloud code team were basically like what if instead we just had the sub agents pass information directly from one to the next via code instead of having a model.
So rather than having a model wrapping every single sub agent and incurring a cost at every single join for tokens like input and output tokens, what if we just had some kind of code wrapper that would carry over every result from one sub aent to next sub aent instead which means that the main orchestrator's context window would never actually fill up because none of the outputs actually go into the main orchestrator. It's going inside of a code file instead. So we would have a JavaScript file where we can define different phases. So we can call a sub agent by doing agent and then pass in a prompt. So it can be like review and this will be a review agent.
Now we can then see if the review passed and if it does pass then we can just end it as it is. The workflow stops but if it doesn't pass then we can fix those issues. So every time we run this agent function then it calls a brand new sub agent in the background. And one of the great things about this is that we can combine code with conditionals and loops. So we can have a workflow that looks kind of like this where we have an implementation phase to implement a feature and then we can go through three rounds of review whereby we have a review sub agent that will review that implementation maybe from different angles in parallel and it would then output that result into a schema. So this schema is kind of like a structured handoff between agents. We would then see if that review passed. If it did, then we would end the loop as it is. If it didn't, then we would continue the loop and fix those issues with another agent. So, let's actually go ahead and run a workflow just like this. So, firstly, you want to go over to cloud code and then run /config. And you want to make sure that you have dynamic workflows enabled over here. And then once that is enabled, we can then write workflow. And you will see that it becomes a rainbow. And it says dynamic workflow requested for this turn. Or we can go to slasheffort and then turn on ultra code for this uh session. And that will basically make cloud code switch to extra high thinking and automatically enable workflows whereby whenever we give a prompt it will look whether that can be done inside of a workflow. But we're going to switch to high and just use a workflow keyword instead. So, I'm going to tell Cloud Code, can you implement a workflow whereby you add a sale banner to top of a landing page for $100 off and you do three rounds of review and you make fixes for the review as well. And if the review catches nothing, then you end early. You will see that it then calls a workflow tool with JavaScript on the inside that includes a prompt and a whole bunch of other things as well like different schemas, uh, conditionals, if statements, and stuff like that. So this is a pretty long workflow that will run.
And just for context, this is a sale of my cloud cod and codex masterass which is the most comprehensive class on cloud coding codeex that you will find on the internet with over 290 videos covering pretty much every single feature and it's updated almost every single day. So a lot of people have told me that this is underpriced relative to market for what the class offers because no other class online comes this close. So I will be increasing it at the end of the sale.
So, if you want to lock in now, then there will be a link down below. There is also a 14-day money back guarantee as well. And less than 0.2% of people who purchased it have asked for a refund because everyone has gotten value out of it. Thousands of people, many working at some of the world's biggest companies have already taken this and have found a lot of value out of this. So, I'm almost certain that this is the last class that you will ever need on this subject.
Anyways, we can now see that it's asking us to run this dynamic workflow. So it's outlined the stages over here and what will happen. And I can view the raw script as well by pressing enter over here. And this is a raw script for the workflow. So I'll be going into more detail about how this works later. But I'm going to press yes, run it, and then it will get set up with the dynamic workflow down below. So pressing enter over here, I can see we have a couple of different phases. We have the implementation phase, the review phase, the fixing phase, and it will oscillate back and forth between the review and the fixing phase. And then finally we have the verification phase. So I can click on this go into this then go into this agent and then I can press enter to kind of like see the prompt as well and then press J and K to scroll up and down to see what this is like. Now going back I can also press save to save this as a workflow. So I will call this implement review verify and this will be saved into a project which means I can use it again or edit it for general purpose use later on. And then this is what it looks like over here. So this is all JavaScript with if statements, conditionals, loops, and stuff like that. So I can then commit it to my GitHub or share it with the rest of the team. Now I want to go through how a file like this even works to begin with so you get a better sense of it. But this file is really long. So I will be going through a much simpler example. So we have a triage sentry workflow and bear in mind that cloud code will be writing these workflows for us. But it still helps to read through the code in a simple example to know what's happening behind the scenes. So at first in the workflow we have a meta at the very top for the name description and the phases. We then define some schemas.
So this will be the schema section. So we have an issues schema and then we have a verdict schema. So we have like the ID of the issue, the title and then we have the number of users that are affected and then we can pass in any arguments as well. So when the workflow is called we have an option for arguments at the very top. So we can pass in like minimum 20 users. We only want to triage the issues affecting more than 20 users and then we can pass them over here. So this is our threshold where the default is 20 but we can change it to be like 10 or something when we're calling this workflow. Then we have the first phase which is we pull the issues using the sentry MCP in the schema that we defined up here for the issues and then we can run some plain JavaScript where we basically filter to only issues that affects more than the minimum specified number of users. If we have no issues that affect more than 20, we can just end the workflow as it is.
Otherwise, we can now continue with a pipeline. So, we basically have all the issues that are the big issues. We then pass it into stage one, which fixes the issue and then stage two that verifies it. Now, pipeline basically allows us to run many things in parallel with results being streamed from one to other. So for example, let's say that we had five issues, rather than waiting for five different agents to first fix the issue and then to verify each fix, we have them run one after another. And what you notice here is that we can also pass in the issue from earlier on. So we had the ID, title, and user account. This now goes into next prompt. So essentially, we have a structured handoff. Rather than all this information going through the model orchestrator, it's just being passed into the next sub agent via code instead. And then finally at the bottom we can return some data for us to view after the workflow has run such as how many candidates have been found for issues, how many of them have been fixed and then some other results as well.
Anyways, our previous workflow is still underway. So the implementation is done.
We've gone through two rounds of review so far and we did two sets of fixes and now we're going through another round of review which will be the final round before we verify that everything works at the very end. Now essentially the toolkit that we have for workflows is that we have a agent which is spawning a sub agent. We have a schema which forces a structured answer back from an agent.
That's really good for a structured handoff. We can run many agents in parallel. So we can run like 8 10 20 agents in parallel. And then we have a pipeline where we can stream results from one agent to the next agent. Now if we quickly go over to the diagram that they shared the cloud code team shared then what we have is we have a pipeline of an implement verifier and fixer right over here. So this is one pipeline and then we have this pipeline being run in parallel many times over which means that the fixer stage of task one only needs to wait for the verify stage of task one to be completed and it doesn't depend on the verify stage of task two and task n. Now when you are spawning a workflow you can also tell it to define a budget. So for example you can basically have something like whilst the budget remaining is greater than 50,000 tokens then you should spawn another agent to try and find another bug and when we run out of budget then we can just basically stop. So this can give you a bit more control over the tokens that you're spending inside of your workflows. Another neat thing that we can do is also resume workflows as well.
So for example, let's say you ran a eight stage workflow and then you finally notice like okay I actually need like a ninth stage as well. You can just tell cloud code to add a ninth stage to workflow and then resume from the same run ID. And that means that the first eight stages will not run again. Only the ninth stage will run instead. So this is another thing worth bearing in mind when using workflows. Now let's quickly go through some more examples.
Now you may get a PRD and you tell cloud code to launch the PRD in a red green refactor workflow. It will do something kind of like this. So it will have a first step which is basically writing a failing test. It will then have another step of running to make sure that it actually fails. It will then do an implementation in another step, another agent. It will then do a nova run in another agent. maybe a weaker one like Haiku or Sonet because you can have different models used at different points of the workflow. And then once a test passes and is green, you may want to do a refactor to kind of clean up any loose ends or make it better code overall. And you can just kind of have this running in the background over and over again getting through a PRD backlog for example. Let's quickly look at another example of dead code sweep. So we have our meta at the very top. We have what is defined as dead code. So the file, the symbol and the kind over here. Then we basically run a while loop with a find stage. So we look for dead code. If we have nothing that is found, then we can continue. And if we have two empty rounds of like we run this loop two times and no dead code is found, then we can exit out of the workflow.
But if we do find dead code, then we can then do another phase of removing it.
And then for any dead code item that we find, we can then run a removal phase whereby for every item we have a different agent running in parallel actually looking into item and then removing it. So these are the parameters that we define. We have it automatically end after eight rounds or it may end early if two rounds find no dead code.
You may also want to make a workflow for doing any deep research for example. So you could have a top level question and then that can be decomposed into a set of smaller questions with another agent.
Each of these sub questions will then be launched in parallel inside of their own pipelines. So one of these lines is a pipeline. This is another pipeline and so forth. And of course you can also have pipelines inside of pipelines as well. And then we can have different models doing searching a line. We may have another one doing like fetching a line and extracting the relevant data.
and then have a opus level model writing a sited answer with all the details from each of these sub questions to answer the main question instead. Now, honestly, I do think that this is one of the most powerful features that Claude code has implemented and I imagine that many other coding agents will be copying it over. I will be going to these concepts in much more detail in my master class with an upcoming class called Loopy AI. So, if you want to learn about that and get in on the sale before it ends and also become a top 1% claude code and Codex power user, then there will be a link down below if you're interested. head.
Related Videos
VALORANT's Latest 'Exclusive' Tier Bundle is Rough...
KangaValorant
17K views•2026-05-28
Flight Attendant Mocks Poor Looking Black Woman — Mid Air Announcement Exposes Her Real Power
SkyboundStories-b4r
184 views•2026-05-28
I FIXED My Friend’s Blown Turbo RX-8… Then Sold It
Cameron-RX8
134 views•2026-05-28
NewsWatch 12 at 5: Top Stories
NewsWatch12
1K views•2026-05-28
Simon Jordan & Danny Murphy deliver PREDICTIONS for Arsenal's Champions League FINAL with PSG
talkSPORTArsenal
6K views•2026-05-28
Botting is OUT OF CONTROL in Classic WoW (Again)...
SolheimGaming
108 views•2026-05-28
The "AI Job Apocalypse" is CANCELLED!
WesRoth
9K views•2026-05-28
STREET FIGHTER 6 - INGRID Story Walkthrough @ 4K 60ᶠᵖˢ ✔
RajmanGamingHD
12K views•2026-05-28











