Anthropic's Dynamic Workflows: What Everyone Gets Wrong!

Added: 2026-06-02

[00:00:00]A developer tried to recreate dynamic workflows from Anthropic and he blew through 2 billion tokens.

[00:00:08]That could have easily cost him a fortune on Opus 4.8. So, I wanted to create this video about dynamic workflows, but I wanted to address a different question.

[00:00:21]First, we're going to look at what exactly dynamic workflows are because I think there is a lot of confusion around it.

[00:00:28]With a lot of misinformation, then we're going to compare it. Why do we need it if agents, subagents, and teams are present?

[00:00:35]Then, I'll show you an example of workflow.

[00:00:38]But most importantly, I'm going to show you when and when not to use them because they are not designed for every task.

[00:00:46]And that's why people are burning through thousands of dollars without getting any gains. Okay, so we need to start with one single agent. And the most important thing I'm going to keep repeating in this video is where is the plan?

[00:01:01]So, if you're using Claude code in a single agent mode, it can read files, it can look at tool results, and everything stays in the same context window.

[00:01:12]So, if it has to decide to take some actions and make a plan, it's going to be as part of that context window. Now, Anthropic recently came up with this primitive of subagents where you basically have an orchestrator that is going to divide a task into subtasks and then assign it to subagents with each one having its own context window.

[00:01:34]But still, the plan is part of the orchestrator or lead agent and it collects results from all of the subagents.

[00:01:44]Now, the problem is none of these subagents are talking to each other. So, the separation of concerns is great.

[00:01:49]However, you can have multiple subagents doing exactly the same thing multiple different times or not know what other subagents are doing. Now, to solve this, Anthropic came up with the idea of agent teams, which is a basically a coordinated sessions for agents.

[00:02:07]Now, in this case, you have the main orchestrator that creates a shared task list, and then you have agents that are going to get a task from this shared task list, and also are able to communicate with each other. Now, in this case, the plan is basically that shared task list, but still in the context window of these models, cuz they have to read that specific document. Okay, before looking at dynamic workflows and how it fits into this new design patterns, we also need to look at slash goal. This is a new primitive or pattern introduced by OpenAI. Now, Anthropic is also adopting it.

[00:02:52]And the idea here is that not only you need to provide a task to the agent, but also a completion criteria.

[00:03:02]So, in this case, the agent is going to perform some actions, and it's going to look at whether it has accomplished based on the completion criteria that you have provided.

[00:03:10]If it hasn't, then it's going to go back and try other things.

[00:03:15]Okay, so let's revisit it. And the main idea again is who holds the plan.

[00:03:20]So, for a one agent, it's going to be within the context window. For subagents, the lead orchestrator is the one that is holding the plan. For our agent team, it's a shared task list.

[00:03:33]However, when it comes to dynamic workflows, it's a real script, actual code that holds the plan, not a subagent or a main orchestrator in its context window.

[00:03:46]Now, this is a very important part of what makes dynamic workflows more powerful compared to other patterns that we have seen so far. Now, I'm going to try to explain this more concretely, but let's look at what a dynamic workflow is.

[00:04:03]Now, irrespective of what patterns that you see, you can have intercommunication between different agents. In case of dynamic workflows, Cloud is going to generate JavaScript scripts with one orchestrator that is going to divide the task into multiple subtasks.

[00:04:23]Each one is going to be implemented by an agent. Then you have independent verifiers, which are basically doing adversarial reviews of the implementation. And the goal here is to actually poke holes in the implementation. And then everything is collected through a fixer, and then we have the main orchestrator that gets the final results and combines everything together. But in this case, Cloud writes that whole tree as a script.

[00:04:58]A runtime runs it in the background, and the results live in the scripts variable, not Cloud's context window.

[00:05:06]Now, since this is a script, you can actually go and look at it.

[00:05:10]And here's kind of a structure of what this script looks like. So, you have the initial metadata, then a phase call to label a stage, then you have a parallel that basically fans out mapping over a list of files, each one handled by an agent call with a schema, so the output comes back structured. Now, the final agent call returns the report that's going to contain agent, parallel, pipeline, and workflows. Those are the basic primitives that dynamic workflows uses. Now, a Cloud writes this way you, but you can easily read it. The most important thing is the plan is now a versionable artifact that you can access. Okay, so the blog post actually said that it can create hundreds or thousands agents, but there is a limit.

[00:06:02]You can run only 16 concurrent agents at a time with a total of thousand per run.

[00:06:10]So, even though uh they say they can run a lot of parallel agents, it's still limited to 16 concurrent agents. Let's talk about what makes them special. And this is this implement, verify, fix loop.

[00:06:26]But, it's not just verification. It's adversarial verification where the agent has its own independent context window, and it adversarially tries to poke holes in the implementation.

[00:06:40]And then there's an independent fixer, which tries to fix.

[00:06:45]Now, for all of this to work, there needs to be verifiable test suite. But, we kind of have seen these patterns.

[00:06:54]If you have executor, verification, and then fixing, but all of them have different context window, and the shared information is only task-related information, you seems to get better outcomes. Okay, but one thing that you need to be careful about is the price of all that power. Because dynamic workflows can burn through your tokens. And the example that we looked at in the beginning was somebody burning through 2 billion tokens.

[00:07:25]Now, fortunately for him, he was trying to use DeepSeek instead of Opus 4.8. Otherwise, there would be a big hole in his wallet.

[00:07:35]So, the main takeaway is that not every task is designed to be implemented using dynamic workflows.

[00:07:43]And that should be the main takeaway from this video.

[00:07:46]Now, I have seen people use this with things like creating multiple different copies of a website or even rating their own previous skills. This is a really bad application of dynamic workflows.

[00:08:02]You want to have a clear-cut condition of what the path is supposed to look like. Or you need to have a very thorough test coverage if you are migrating a code from one say language to another.

[00:08:18]Now, an example of this is Bun code, which was migrated from Zig to Rust. And Anthropic highlighted this in their blog post. Now, the reason they were able to do this with Bun was that it has almost perfect level of test coverage.

[00:08:33]And in order to figure out whether the migration was successful or not, they were able to measure how accurately it was passing the test suite. Now, still it was not really perfect. There were more than 13,000 unsafe blocks compared to only 73 in the handwritten Rust. So, even if it's able to do the migration for you or implement something for you, the main takeaway is that it may not be production-ready.

[00:09:06]Now, so let's look at some bad examples of this.

[00:09:10]If you don't have ground truth, which means you don't have unit tests or verifiable rewards, it's basically based on vibes now. So, if you use dynamic workflows for writing 10 different copies of your website, the model doesn't know what exactly good looks like. So, only reach for workflows when you have something objective that can be measured and the agents can see what good looks like. Okay, so here's a very simple decision tree that is going to help you when to use dynamic workflows.

[00:09:46]So, the first question you should ask is that is there an objective oracle or a objective measurement?

[00:09:53]If the answer is no, then you shouldn't use it.

[00:09:58]If the answer is yes, then you need to think about whether you need massive fan out of hundreds of agents.

[00:10:06]If the answer to this is no, then you probably should just use a single chart or sub-agent orchestration.

[00:10:13]You don't need any estate mid-run, then go with {slash} goal.

[00:10:17]Now, if answer to all of these is yes, then I think dynamic workflows is a really good candidate for what can be done with them. Now, more concretely, the sweet spot is if you have code-based white bugs or security sweeps or large migration or hundreds of files, maybe deep search where sources cross-check each other. These are really good examples for something like dynamic workflows.

[00:10:47]On the other hand, if you have creative or subjective outputs, very small well-scoped changes, and anything with no automated correctness bar, this is where you should try to avoid using dynamic workflows because they're going to be a lot more expensive than using a sub-agent pattern or agent teams. Now, apart from parallelism, here's how I would basically describe dynamic workflows in three lines.

[00:11:16]It's code, not context. You need to have an objective measurable outcome for this to be actually useful. And run this wisely because the power comes with a lot of cost. Okay, so let me show you how to use this in practice.

[00:11:33]So, if you open Claude code and you type workflows, you actually see that it adds this pretty neat animation.

[00:11:44]And in here you say dynamic workflows requested for this turn, right? So, this is one way you can just include this in your prompt and it's going to activate dynamic workflow. Another way is to go to the effort and within effort, if you try to set it to ultra code, this is where it's going to activate dynamic workflows for you. So, what I'm going to do is I'm going to just go to extra high and we're going to just use it by invoking it in the prompt. Okay, so to show you a practical example of this, I'm currently working on an app called Quorum. Think of this as granola, but completely local. So, it can transcribe your meeting. It can figure out what are the different action items that needs to be taken. And also, based on all the previous conversations, it can find what are the relevant meetings that you might be interested in.

[00:12:43]Currently, this is running completely on Mac OS and I built it with MLX Swift. But now, I want to migrate all the models to transformers instead of MLX.

[00:12:57]Now, the main thing is that this code has measurable outcome. I can tell what exactly to measure in order to define the success criteria.

[00:13:08]So, I can say something like this.

[00:13:11]Create a workflow to migrate all the models that we are using from MLX to transformers.

[00:13:19]Make sure to to test it against the MLX implementation.

[00:13:24]It highlights the workflow. Now, if we start this, this is going to look at the existing code base, and then it's going to dynamically decide how many sub agents it needs. So, we're not telling it how many sub agents to use.

[00:13:40]Uh so, right now it says that uh it's going to start with understanding the code base, specifically the MLX implementation. Orchestrator is going through the code. Okay. So, based on its analysis, it's asking for some clarifications and questions. Since this is going to be a token-intensive task, so they have a human-in-the-loop component in the beginning that you actually accept what it's going to do.

[00:14:05]Okay. So, after the initial assessment, now it's launching the workflow. Okay.

[00:14:09]So, when it's ready, it's going to ask you dynamic workflows can use a lot of tokens quickly by running many sub agents in parallel, which counts against your usage limit. This is important because you need to actually think about whether it's worth running the workflow or not. It also gives you the script that you can actually see. So, if you recall, I said that it actually writes a script and everything is part of the script, uh not just something in the context window of your agent. Okay. So, if we say yes, run it, then it's going to decide how many sub agent it's going to actually need.

[00:14:53]So, right now it decided that I will do it in four phases with nearly 12 different sub agents. If you go to workflows, you can actually see what stage uh this whole orchestration is, and then also how many sub agents are there, and what is their status. So, right now it's in the design stage in our case. It also tells you which model it's using. Uh and you can actually see how many tokens were used across how many tool calls, right? So, it gives you a really uh great insights into what exactly is happening under the hood. All right, so it's still going strong about 200,000 tokens. And again, look at the workflows. So, right now uh there are three different agents. Two of them have completed.

[00:15:47]And we can actually look at how many tokens each have used. This one seems to be uh the most expensive one in terms of cost. All right, so right now we are in the implementation phase. So, at this stage there are seven different agents that are currently working. Three of them are still waiting. Seems like the build is complete for everything. It decided to use Open Opus 4.8, which is a good choice. And right now it's just running through the test. Okay, so seems like the implementation is complete. It passed the tests. Uh it used about 750,000 tokens. And now here's the app. So, I think it's uh recording. And I'll have to test it in a meeting to see whether it works or not, but seems like the transcription uh is working. If I stop this, uh right now it's transcribing and summarizing everything. Now, in the back end, I think it's uh still doing a few things. So, this might not be fully functional. So, this was a quick example of how to use workflows and how it's supposed to look like in practice. Now, I hope this gives you some clarity on what exactly dynamic workflows are, when to use them, and when not to use them, because with great power comes great responsibility. Don't just try to use the newest feature out there.

[00:17:13]You're going to burn through your token quota pretty quickly. I hope you found this video useful. Thanks for watching and as always see you in the next one.