Clud workflows dropped about a week ago, and they're not really getting enough airtime. And I think the reason for that is that they can feel a little bit abstract like, hey. You can run something called a workflow now, and it'll burn millions of tokens. But there are some real gems that, dare I say, are
game changers. So I'm gonna break down what workflows really are, how they work, and the six patterns
that you can use to make them with real examples. And if you want any of the ones that I show you, there will be a link in the description below. And so credit where credit is due, the best description of what these things are and how you can use them actually comes from Anthropic itself. So a lot of the things I'm gonna go through in this video are based on this documentation.
So at the most abstract
level,
Cloud Code itself is an agent harness that is mostly
built for coding, even though there are other use cases and types of tasks. But inevitably, there are these certain types of tasks
that you might wanna do really well that ClaudeCode itself out of the box isn't particularly great at. So things like researching,
security analysis,
using agent teams, running code reviews,
those are the types of things where ClaudeCode
itself
isn't super well suited to actually do those things in-depth.
And so what workflows do is they allow you to dynamically
create these, like, different harnesses on the fly. So that, like, in a pretty easy way, you can create these reusable
harnesses
that can solve pretty complicated problems in a a much easier way. So a few plugins out there, like Compound Engineering,
for example, they tried to build these types of workflows into their skill files in the way that they would use sub agents, but now that stuff is just supported directly inside of Cloud Code. So one example just to, like, ground everything we're about to talk about, this new deep research that rolled out with Opus 4.8 and these workflow releases
are an example of a dynamic workflow.
So what this thing specifically does
is it can fan out and do a bunch of different web searches.
It can fetch all of the sources,
Then it adversarially
verifies the claims with separate sub agents.
And then finally, synthesizes all of that back to you in a cited report. So this is an example of a dynamic workflow.
And so this is something that you could have tried to force together in the past with different, like, skills and commands and trying to, like, manually call them and string them together.
But now it's better, it's more seamless, it's supported natively, and it's easy for you to create these things with natural language. So how do they work? Uh, first things first is that you need to have the agent, obviously, that's powering all of this stuff. But then there are two things that make this, like, different and what constitute it being a workflow.
Number one is that it can run things in parallel. And so in this case, what happens is that you can pass it, like, all of these different things that it needs to accomplish,
and it can run all of them at the same time, and then it waits for all of them to finish.
So for example, if you were gonna run, like, a deep research report, it would go out, it would run all of those like search queries and exploring your code base and all that stuff at the same time, and then would wait for all of them to come back together. The second piece is a pipeline.
And so in the cases where things don't have to wait for all of them to done and they can be run-in order, we are running a pipeline. Now the thing is when we're working with workflows, it doesn't need to have both of these. Either of them can be used individually,
or depending on the workflow, they can be combined. So here's, like, very concretely what this might look like in practice. So if you were to ask, for example, should we migrate our checkout service to a new provider?
Inside of, like, the static
traditional, like, clawed code harness, this might turn into, like, five different web searches.
It fetches the top results from those web searches.
It verifies
what it found, and then it summarizes it back to you and gives you a generic research report. And so, for example, like, can have a skill that instructed it, like, hey, you need to go through these stages. So what makes a workflow
different? Well, in a dynamic workflow, it might first go out and read our actual, like, current, like, Stripe integration or billing code. So maybe it identifies that there's three different, like, primary functions inside of the the app that handle these things. It then takes all of that as context
and checks each of our features against, like, the new provider that we're considering documentation.
It also has a separate agent that's trying to price out, like, based on the volume that we're doing.
What is the cost consideration within this? And then maybe you have an adversarial review stage that kicks in, and it takes all of, like, the individual context that it's been getting from these different sections.
And maybe it tries to make a case against
migrating.
And so the result of this is that you get a much more specific
set of recommendations out the other side. So this is, like, fundamentally what the the difference is between, like, a static harness
versus these, like, kind of, like, customized harnesses
via a dynamic workflow. So in a bit, we're gonna go through, like, some very concrete examples of these things. But first, I wanna walk you guys through these six patterns that can be used to construct any number of workflows.
So again, the one thing to keep in mind as I go through all of these things is that they can and probably should be combined together. So we're gonna go through again some of those cool use cases after we talk about what each of these things actually are. The first pattern up is called classify and act. And this is where you would give in some sort of task.
It can then classify
that task and like what it really means. And then it can route that task to specific agents, depending on, like, the logic that you set of how it chooses to actually route something. So a really simple example of something like this might be, like, handling, like, bugs and edge cases inside of your app. So you could have a workflow that classifies
those bugs based on, like, the severity or the complexity.
And then depending on exactly where it falls in that spectrum, maybe you're handing certain things off to, like, Haiku to solve, like, very basic things. Maybe you pass, like, medium bugs off to, like, Sonnet with a systematic debugging type of skill. And then maybe your most complex issues get passed into, like, Opus, for example. So this would be an example of the classify and act pattern. The next one up is called fan out and synthesize.
So this is where you take a task, you split it up into a sequence of smaller steps. Each of these steps runs individually, like, as sub agents. And then the results of all of them get passed back to a synthesizer
that returns you the end result that you were looking for. So again, a really well known example of this is going to be like a research style workflow.
So maybe it's going out first and it's exploring your code base, then it's pulling in, like, actual documentation
from providers, maybe using something like Context seven. Then it's looking for, like, common use cases that are circulating online. And then after it has all of these things, it's gonna synthesize all of that into a final result and report back to you. So number three and one of my favorite of these is the adversarial,
like, review and verification
type. And so one of the big downsides of language models is that they really tend to lock in on narratives. Meaning, if something comes out of the context that you've been generating,
it might find one thread there, turn that into some sort of story,
and then start jamming that story down your throat, when in reality, like, the claim isn't that verified,
and it just locked into some direction.
And now it has, like, blinders on, and it won't consider anything outside of that. And so the thing that's really cool about this adversarial approach is that we can challenge all of the claims and premises with a fresh verification
or, like, adversary.
That is really, like, a forcing function. Like, it's forcing the model to debate back and forth with itself with fresh context
so that any of that, like, narrative lock that was taking place kind of fades away, and you can spin up a bunch of these at the same time. So for example, each of these different, like, adversarial verifications that are taking place can all have, like, different definitions and scopes of what they're actually looking for when they're evaluating this claim. So the fourth is called generate and filter. This is one that I think compound engineering does really well, where we have different agents that are solely responsible for generating, like, ideas, for example,
with different prompts about, like, how they specifically
think about generating ideas.
Then you get a big list of ideas out the other side, and you can actually filter them down based on a, like, a rubric, a set of criteria,
overlap between them. And then finally, from that, you get, like, the best ideas out the other side, and the ones that didn't fit your criteria get discarded. And so you can imagine you wanna, like, brainstorm different approaches to some feature that you have in your mind. You could kick off three different sub agents that are thinking about how to solve that problem from different perspectives.
And then you could filter all of the ideas that pop out the other side based on, like, the context of your app, the dos and don'ts of your app, maybe, like, your business or marketing standards, depending on, like, the use case that you're using this for, because this isn't just for coding use cases. And then again, you're returning just the best ideas, like where maybe you wanna take that that feature, maybe what the UX approach for that feature should be. It's really sky's the limit if you get creative with how you wanna use these things. So again, in a few minutes, we're gonna get into how you can combine all of these together.
But first, let's finish up with the last two. So the fifth one is fun. It's called the tournament, and this is where you're spawning agents to compete on the same task. So each agent here is attempting to solve the same task using different approaches. And then we have a judge model that is judging the outputs of all of these things and trying to get down to, like, what is the actual winner. So this one almost feels like a combination of the generate and filter and the adversarial
verification.
But the difference is that we are going through rounds. So for example, we have these two different competing ideas that result in one winner, but then we had the secondary round that had its own test it was running that resulted in its own set of winners. And now we're gonna pair these two winners against each other in battle until we get to our final result. So maybe you're trying to brainstorm, like, the best UX approaches for your app, and each of these different attempts that you are launching is, a different approach to how you could think about the user experience. And then we're taking those winners, pitting them against each other, and finally landing on, like, what is actually the best approach to the UX for this feature or for the app in general. Or maybe you're trying to brainstorm viral hooks for your marketing campaign based on the hook library that you lifted off of your favorite YouTuber.
That type of system would work equally well here. So the last one that we have here is called loop until done. And this one out of all of them is probably the one that gets used the most with others.
So it's pretty straightforward. What this thing does is it's gonna continuously
loop through a problem
until a set, like, acceptance criteria is met, and it knows that it's complete. So maybe, for example, you realize that you just built this entire app and you weren't following, like, a test driven development approach, and now you have, like, no testing across your entire app. You could kick off an agent that's meant to discover
all of the areas of your app that are untested.
And then for all of those new findings,
you could kick off a sub agent. That sole responsibility is to find the riskiest areas of your app that are untested,
and it just continues to loop through this until, for example, it has, like, a certain percentage of test coverage across all the different, like, functionality inside of your app. So this one, like, feels kind of similar to a Ralph loop, but it's it's a little bit more flexible, I think, in how you can actually invoke it and the logic it uses to to get things done. So like I said earlier, there's a lot of use cases where you can combine these things together. So let's go through a few of those and talk about which ones they are combining.
So one good example of this is the built in deep research workflow. So let's say, for example, that, like, you have an app that uses a language model, and you realize that, like, you might not be efficient
with the amount of turns that are being taken, how it's, like, summarizing information,
how it's cashing tokens,
all of that type of stuff. And you know that you need to put something like that inside of your project so that your costs don't, like, get blown out of the water. Well, you could run a deep research workflow
that first goes out and it fans and synthesizes.
So it's gonna break down what that query is, like prompt optimization techniques for an app that does x, y, and z. And maybe it goes out and it determines that it needs six different sub agents that are gonna go out and they're gonna look at, like, different components
of what you asked. After it takes into account all of that research,
maybe then runs it through an adversarial
review. And what that review is looking at is it's looking at the context of your code base, the conventions that you already have in place, the problems that your app is actually meant to solve, the tech stack that you are actually using, and it's going to fact check each of these claims that came through from the fan out stage to make sure that they are actually accurate and make sense given the context of your project specifically.
And then after all of that is done, it will synthesize it down into a set of concrete recommendations
for you. Now one of the things that makes this, I think, a little bit stronger than something like a
skill is that as findings come out of the research or the adversarial
review, it can continue to iterate and improve
the quality of what is kind of going on. And we'll look at an example of that in a second where I show you, I think it's the third example that I have, where it starts spawning a lot of different sub agents to resolve things that are coming up in real time. So another use case of these things being combined together might be fact checking your meta prompts. I think one thing that people love to do is to tell their tool to go out and, you know, research something, and then, like, build a skill that replaces
twenty years experience in some field. And again, these models are prone to narrative
lock in. So if you're not, like, really fact checking those things and verifying everything that gets encoded into those prompts or those skills,
you could be doing things that, like, just simply aren't correct, because the model has convinced itself that combining those things together actually
reality, it may not really make sense. So for example, you could have a classify and act pattern that actually checks through that, like, meta prompt or skill, and looks for all of the things that are being claimed to be a fact. And then based on all of those facts that it uncovers,
it can act toward a adversarial
review that then actually loops through and looks at all of those claims,
researches them, and make sure they actually make sense and integrate
with the skill that you had in the first place. So now we're gonna go through two real concrete examples of these that I have made for myself that combine about three patterns, I think, each one. So the first one is mining from your session history
updates that should be made to your Claude Markdown file. So a lot of people, like, create a Claude Markdown file once and then forget about it for eternity.
And the Claude Markdown file is one of, like, the most important things for you to keep up to date if you want to vibe code, like, a total Chad
and not become a meme that someone talks about on Twitter with having AI slop and such. And the reason for that is that you really wanna document
patterns and conventions inside of your project that are not obvious.
So Claude code and really any tools that supplies just as much to like something like Codex.
They're really good at understanding things that are very clear patterns.
But anytime they would have to read like a lot of stuff to understand something that could just be explained
in a sentence or two, or if there are things about your project that would not be immediately
obvious
from a language model just reading your project, those are things you wanna have inside of your Claude Markdown file. And so here's what this workflow does. Step number one is a discover and digest.
So we can think of this as, like, a fan out pattern, where it is going to take the last 20 conversations
within this project, like sessions I've had within this project. And then it's going to loop through all of those sessions with parallel agents
that read chunks of the session, and then propose anything that came out of that session that is a potential candidate for being included inside of the Claude markdown file based on, like, the rules that I gave it, which in this case were, like, things that are not easily inferable
from, like, what is already inside of the project. So we're grabbing all of our chats. We're mining them for, like, opportunities
for potentially updating the clogged markdown file. And then we're running through an adversarial
verification,
where it's gonna take all of those candidates,
and then it has two different, like, skeptic lenses
that is gonna look through to think if it needs to reject this. So the first one is the structure lens, which is going to try to see if what we're saying should go in that Claude Markdown file is easily inferred
from what we already have in the project. And then it has another one that looks at, like, the novelty or truth
of what actually came out in this mining loop. So is this already in the clawed markdown file? Is it not a real pattern that needs to be documented?
Or is it simply not really supported by the evidence? So then it continues that process for two rounds, seeing if, like, okay, well, I loop through this again, am I finding anything new? And again, these are all, like, fresh agents, so fresh set of eyes. And then once that's all done, it synthesizes it down into a report for us. So this is a good example of where we're using, like, at least three different patterns,
and we're doing something that would be, like, very convoluted and difficult to replicate inside of something like a like a skill.
And I will get into, the end of this video, the best practices so that these things don't run away and blow through millions of tokens. Because full disclosure,
this one did use millions of tokens to do this. And the reason that happened is because I didn't follow my own best practices that I'm about to discuss with you. So if we wanna look at, like, well, what does the output actually look like? This thing ran, I think, for about twenty, yeah, twenty six minutes.
It read the 20 sessions that I loaded it up with. It looped through six different times, which is definitely overkill.
And it ended up finding 10 candidates
that survived two different adversarial passes.
So in this case, like, the project that we're we're using here, this is like one of my, like, paid plugins that people get inside of my community. And I have certain, like, conventions that I like to follow when I am improving this and, like, releasing updates and doing all that type of stuff. And so what this was looking for in this case was my own cloud markdown file for, like, maintaining
this thing that I build for other people. And so I found a bunch of different things, tooling and runtime issues inside of the project,
invariance across files, like things that are different and, like, break from patterns and conventions,
Details of, like, how different plugins and skills actually work together, like, aren't obvious without actually going in and reading those skill files. And then it actually found some things that are now out of date. So I didn't actually update my Clawdermarkdown
file, and now what I specify in there is not actually correct. So for example, I have like this visual verification loop skill,
which was originally stubbed as I was building this thing out, but now I actually have the full version of it. And so the clawed markdown file is saying that this is a stub, like, is no longer accurate. So these are all things that I would wanna move through then and update.
And,
we're gonna get into, like, some of the best practices of this in a second. But before I do that, wanna walk you through another workflow that I think is pretty cool. This So one is called the React Refactor
Tournament. And so what this one is gonna do is it's going to invoke Vercel's
React best practices
skill. So what this one is gonna do is it's going to identify
the candidates of optimization
using that react best practices skill. It's gonna have judges identify which of these are actually the bigger issues inside of the project based on the context of the project and the severity of the thing. It's gonna have one winner from that, and then it's going to continue back through that loop of identifying the issues,
running them through this tournament, and finding the winner for as many cycles as we tell it to. In this case, it's defaulting to three cycles so that it doesn't go crazy. And so if we wanted to pop in and, like, see what this looks like as it's running in real time, they actually have this, like, phased system where we can see, like, what are the phases of this workflow that are actually
running. So in this case, it's first defining, like, the actual scope. It's then moving through a discovery phase and finding, like, all of the opportunities for where we would even, like, want to apply this thing. Uh, part of the skill that I defined is that anything it finds, it writes to a backlog so that we can always go back and reference those things and don't have to rerun the skill. And then it's gonna actually run it through the tournament and make the fixes. So we'll let this thing run for a little bit, and then we'll pop back in and look at the outputs. And so we can see in this case that all of these different tournament rounds are running at, uh, pretty much the same time. Like, they don't need to be run necessarily,
like, in a strict pipeline where, like, one needs to wait or, like, anything like that. These are all running in parallel.
So when we talk about, like, why this stuff can consume tokens,
the number of, like, tasks that are gonna be done can balloon quickly if you're not, like, really aware of what type of workflow you're kicking this thing off on. So if the idea of running, like, 19 different sub agents at the same time is something that's, like, scary to you, Again, we'll get into some of the best practices in terms of, like, how you can control these things so that you don't end up with a session that is just, like, blowing through tokens like crazy. One thing that I will say, though, is, like, in this case, for example, the React best practices gives you, like, really good detailed guidance on what to do, and they give examples of the types of fixes. So honestly, if we had run this on Sonnet, it probably would have gotten, like, the same quality of work done, I think, without having to blow through this many Opus tokens.
So those are the types of things, though, that, like, you can explain in natural language when you create these workflows,
what models you want it to use for specific,
like, rounds of the workflow, like, all of those types of things. You can control those and configure those things. So the last thing that we'll look at while that is running is like, what does this file actually look like? So these workflows are created as a JavaScript files.
So the meta of the workflow,
you have like the name, the description,
uh, when to use it. If this isn't something that, like, you want to specifically trigger, and that is something to be aware of, these workflows
will run by themselves.
And so you wanna be, like, very clear about the when to use kind of, like, meta field so that it doesn't go off and do crazy stuff. But then we have, like, what are the different phases
that are gonna actually run inside of this thing? And this is how we're getting that structure inside of that workflow,
where we have, like, the scope, the discovery, the backlog, the tournament, the fix. All of this was created in natural language by me describing what I wanted to happen. And then the rest of this file is just giving it the logic of how it's going to actually work. It's very strict on, like, the schema of the thing, so that it's gonna, like, actually run, like, a little bit more, like, deterministically,
and it's not gonna go off the rails and do random stuff. So it is very strict. But, again, all of this stuff gets created
for you. So for example, in, like, that phase one, like, the scoping,
there are very clear instructions on how things are being done, what the tasks are. So all of these things and the configurations, like how many rounds it's running in loops and, like, all of those things are specified inside of this file. Now if this is intimidating, you don't need to necessarily go in and read it, but you should at least be aware that this lives inside of your project in a in your directory
in a workflows folder. And so now what we have happening is that the fixes are actually being done inside of separate work trees, and they are being committed as they are done. And so there's really endless opportunities for how you can combine all of these different types of, like, workflows to compose, like, really great ones that help you solve involved problems. But like I said a few times, you need to be aware of best practices and how you can control these things so that they don't go off the rails and end up burning through tokens. Because I promise you it will do that if you're not aware of what you can control. So these best practices are again coming from from Anthropic directly. So number one is prompting.
You should be very detailed about telling it how to set things up. I actually use the exact language
from these when I'm describing what I want it to do. So for example, with the tournament workflow that we just looked at, I told it, like, I want you to use a tournament with pairwise judges that do x y and z. So being very specific about how you prompt things. You can also tell it that you want this to be, like, a quick workflow that doesn't go crazy. So I think this is part of where, like, the whole, like, it's gonna burn tokens argument goes out the window.
You can force it to do things in whatever way you want it to do. If you give it an open ended task, like, yeah, it might go up and accidentally spin up a 150 agents, But you should see that happening if you're paying attention to what's happening, and then just go in and modify the workflow so that it fixes
that. Number two, using goals and loops. So on the loop side, if you create a workflow,
maybe you created some workflow that can, like, look at failing poll requests, and it it runs through some sort of workflow to resolve that in whatever way you want to. You can run that on a loop, for example, that's going to look for failing pull requests on some sort of interval
and then run it through your workflow. Uh, another thing you can do is use the slash goal command inside of ClawdCode to set, like, an actual hard measurable completion requirement
so that the workflow has context
around when to stop. Number three, and I think this is the biggest takeaway, is you can tell it that it has a token budget. So for example, if you were to go through and say, like, you can only use 10,000 tokens, you can only use a 100,000 tokens for this entire run, it is going to actually adhere to that. So this is, like, a really powerful thing if you're afraid of, like, the number of tokens that are gonna be used or whatever.
Just, like, tell it what your threshold is for this thing being run properly,
and then you won't have to deal with that. And then last but not least, you can save workflows. So you can save workflows, you can share workflows,
and it's really easy to do that. So for example, like, we were to pop back down inside of this specific,
uh, skill, if I was to come through and hit save,
I can give it a name, and now this skill is going to be saved into our project, and then we can reuse it. We can share it. We can put it in a repo and share it with others. Like, whatever you want to do, sky's the limit. So like they say, it's a whole new world. It is, I think, borrowing patterns from, like, things that other plugins were attempting to do, but now it's an extension of ClawdCode, and it actually is going to work that way by default.
And there is a lot of control that you have over the system. Again, if you want the two workflows that I went through specifically and you wanna customize them, which I I recommend you do customize them, you can find links for those in the description below. If you're someone trying to, like, upscale from basic vibe coding into, like, more intermediate vibe engineering,
as I like to call it, you should Hulk smash the subscribe button. But that's it for this video. I will see you in the next one.