How to Launch Hundreds of Agents in Claude Code with Dynamic Workflows

Find more materials on configuring tools in the Ailoot documentation.

What Are Dynamic Workflows, and Why Did Anthropic Launch Them on May 28?#

Previously, the format itself limited scale: one chat = one plan = one context window. Subagents helped, but the decision about “what to run next” remained with Claude in the main conversation, and every intermediate result consumed that same context. This became a bottleneck on a task involving 500 files or ten independent hypotheses.

Dynamic Workflows move the plan into code. Claude formulates the task as an orchestrator script, the runtime runs that script in an isolated environment, and intermediate results live in the script’s variables rather than in your context. The session remains responsive while agents work in the background.

What actually changes compared with the old approach: independent agents challenge one another’s findings, and only what survives cross-checking makes it out. The “dynamic” in the name refers to exactly this: each run is written for the task at hand. There is no ready-made list of processes.

How a Workflow Differs from a Subagent and a Skill: 3 Types of Orchestration#

I choose between a workflow, a subagent, and a Skill by asking two questions: who holds the plan, and where do intermediate results live?

The main shift is that the plan moves into code. With subagents and Skills, Claude is always the orchestrator: it decides along the way what to spawn next, and every return lands in the context window. A Workflow keeps the loop, branching, and intermediate results to itself; only the final answer reaches Claude.

You can run the same plan so that independent agents take it apart from different angles, and the script brings together what holds up. You can’t do that in a regular pass through one chat: Claude has no independent point of synthesis.

Here’s how I choose: for a routine task with several steps, use subagents or a Skill. For a task that doesn’t fit into one conversation, or a process you want to rerun on demand, use a workflow. I covered all four primitives in detail in the pillar guide Skills, Subagents, MCP, or Plugins.

3 Ways to Start a Workflow in Claude Code#

Method 1. The workflow keyword in a prompt. The simplest option; it doesn’t change the session settings. Just insert the word workflow into any prompt, and Claude Code will highlight it as you type and generate an orchestrator script instead of a regular conversation.

Run a workflow to audit every API endpoint under src/routes/ for missing auth checks

If Claude Code highlights the word but you didn’t mean to start a workflow, alt+w disables the trigger for that prompt.

Method 2. /effort ultracode mode. This enables the model’s maximum effort (xhigh) and also lets Claude decide on its own when a task warrants a workflow.

/effort ultracode

In this mode, one request can unfold into several workflows in succession: one to understand the code, another to make a change, and a third to check the result. Each run uses more tokens and takes longer than a regular effort level. The mode applies only to the current session and resets when you open a new one. When you return to routine work, /effort high turns off ultracode.

Method 3. The built-in /deep-research command. A ready-made Anthropic workflow for web research. The next section covers this method.

For all three methods, Claude Code asks for confirmation on the first run and shows a list of phases. The response options are Yes, run it, Yes, and don't ask again for <name> (remembers your approval), View raw script (open the code with Ctrl+G), and No. In Auto mode, confirmation is needed only for the first run; subsequent runs proceed without asking. With claude -p and the Agent SDK, there is no confirmation at all: subagent permissions are then taken from the shared allowlist.

The Ready-Made /deep-research Workflow: A First-Run Example#

The fastest way to try Dynamic Workflows is to run a ready-made one instead of writing your own. Anthropic includes the built-in /deep-research workflow in Claude Code. It explores a question from several independent angles, retrieves sources, votes on each claim, and leaves only those that survive cross-checking in the report.

1. Run the command

   In a Claude Code session, enter /deep-research and frame your question as a detailed prompt. The more precise the wording, the fewer phases the script will waste time spinning up.

2. Allow the workflow

   A dialog will appear with the phases and the Yes / View raw script / No buttons. Approval is saved for the project if you choose an option with don't ask again.

3. Watch progress with /workflows

   The run moves to the background, leaving the session free. The /workflows command shows a list of running and completed runs. Use the arrow keys to select a phase, Enter to expand it and see its agents, j/k to scroll through details, p to pause, x to stop the run, r to restart an agent, and s to save the script.

4. Read the report

   When the run finishes, the report with links appears in the session. Claims that didn’t survive cross-checking are filtered out automatically.

Unlike a regular chat with one web search, /deep-research parallelizes queries on its own and reconciles conflicts between sources. I run it to explore a topic before writing a guide: it’s a convenient way to get a feel for token usage before scaling a workflow up.

Ultracode: The Mode Where Claude Decides When to Start a Workflow#

Ultracode combines two things: maximum reasoning effort and permission for Claude to start workflows on its own. By default, even /effort xhigh runs a regular conversation: Claude thinks longer, but still keeps the steps in its own context. Ultracode adds permission for Claude to turn a task into a workflow on its own as soon as it realizes that one session won’t be enough.

/effort ultracode

When the mode is enabled, one request can launch two or three workflows in a row: one examines the codebase, another makes a change, and a third is a separate run that tries to disprove it. It’s the same pattern of “several independent attempts ⇒ final synthesis,” but without your having to start each phase manually.

The cost is obvious: each request takes longer and costs more than it does with /effort high. Under the hood, several runs execute with their own limits, and Anthropic itself doesn’t recommend ultracode as the default mode. It applies only to the current session and resets in the next one.

When you return to routine work, /effort high turns off ultracode, and the session goes back to being a regular chat with subagents. On models that don’t support xhigh, the ultracode option simply doesn’t appear in /effort.

Limits, Tokens, and First-Run Pitfalls#

The runtime sets these hard technical limits:

• Up to 16 agents running in parallel at once. Fewer on machines with a small number of cores. This is a local resource budget.
• 1,000 agents per run. A safeguard against runaway loops: if a script starts spawning agents endlessly, the runtime will shut it down.
• You can’t wait for user input during a run. Only tool permissions can pause it. If you need to sign off between phases, split the work into separate workflows.
• The script itself has no direct access to files or the command shell. Reading, writing, and running commands are the work of the agents it spawns. The script only coordinates them.
• Claude Code v2.1.154 or later is required. Available on Pro, Max, Team, and Enterprise (Pro is enabled through /config), as well as on Claude API, Amazon Bedrock, Vertex AI, and Microsoft Foundry.

The main warning is about cost.

Every agent in a run uses the session’s model unless the script routes a phase to another one. Before a large run, check /model: if you’re used to switching to a cheaper model for routine tasks, ultracode and /deep-research can run up the bill if you skip this check. You can explicitly ask Claude in your prompt to “use a cheaper model for phases that don’t need maximum capability”—that’s a valid way to manage costs.

If a run goes off track, open /workflows, select the run, and press x. Agents that have already finished keep their results. You can resume a stopped run right there with p, or ask Claude to restart the script from the same point: cached agents return their results, while the others continue working live. This works within one session: once you leave Claude Code, the next session starts the workflow from scratch.

If you’re planning long runs, start managing usage with the guide How Not to Burn Through Claude Code Limits and the Second Brain: with the right project structure, the workflow won’t pull the entire repository into every agent.

How to Save Your Workflow in a Project#

If Claude has put together a workflow for a recurring task (for example, reviewing every branch or performing a regular security audit), you can save the script and stop describing the task in words each time.

1. Open /workflows

   The command shows a list of recent runs. Use the arrow keys to select the one you need.

2. Press s

   A save dialog will appear. Tab switches the storage location.

3. Choose a folder

   .claude/workflows/ is in the project and visible to everyone who cloned the repository. ~/.claude/workflows/ is in your home directory, available across all your projects and visible only to you.

4. Call it as a command

   /[script_name] starts the workflow with the same script as the first time. If workflows with the same name exist in the project and home folders, the project one takes precedence.

This creates an interesting pattern: one person on a team gets a workflow working once, commits it to .claude/workflows/, and each subsequent team member runs the same orchestration with a command. The script is readable JavaScript, so you can inspect it, edit it, and commit a new version.

The first time you run a saved workflow in a project, Claude Code will still show a permission dialog, so saving the script doesn’t automatically approve it. Approval is granted separately with Yes, and don't ask again.

Which Tasks Are Workflows Really Worthwhile For?#

Anthropic explicitly lists the scenarios the runtime was built for:

• Audits across the entire codebase—check every endpoint, file, and function against a checklist. For example, check for missing auth checks, find duplicated logic, or audit security against OWASP rules. A separate agent is spawned for each checklist branch.
• Large migrations—switch frameworks, move away from a deprecated API, or port thousands of files to another language. The workflow tracks progress, agents work on files in parallel, and cross-checking agents look for anything missed.
• Research with cross-checking—a question that needs sources from different angles, and an assessment of which claims will hold up under cross-checking. This is the basic scenario the built-in /deep-research was written for.
• A complex plan you want to sketch from several independent angles—the workflow produces several independent draft plans, opposing agents examine them, and a synthesis is delivered. This is for when “the cost of a mistake is high, and one pass isn’t enough.”

For a task like “fix one bug” or “add one function,” Dynamic Workflows lose to a regular session: the token usage won’t be worth the time. Anthropic’s documentation makes this point clearly: “start with a narrow task to get a feel for the usage.” My rule: if there are fewer than 5 independent subtasks or fewer than 50 files, a regular chat with a couple of subagents will handle it more cheaply.

If you lead a team on an Enterprise plan, an administrator may have turned off Workflows through managed settings or the switch on the Claude Code admin page. Before treating Workflows as a “solution to everything,” check that they’re enabled at all: /config → the Dynamic workflows entry.

Find additional materials on working with tools in the Ailoot documentation.