Anthropic Launches Dynamic Workflows: Main Agents Generate Orchestration Code to Decouple Multi-Agent Coordination

Claude Managed Agents introduces Dynamic Workflows, a feature that offloads task coordination, sub-agent launching, and result aggregation to executable orchestration programs generated by the main agent. This reduces the runtime burden on the main agent. The mechanism is currently in Beta, with technical details and design motivations disclosed at the AI Engineer NY 2026 conference.

Dynamic Workflows externalize coordination logic into executable programs; the main agent only needs to generate and deliver the orchestration code, without participating in runtime scheduling. Drawing inspiration from the evolution of open-source collaboration, this approach directly addresses organizational bottlenecks as multi-agent systems scale.

This article is suitable for AI architects, agent system developers, and LLM engineering practitioners.

Author | Lin Qibei Editor | Cai Fangfang

In multi-agent systems, tasks can be distributed to different agents for parallel execution. However, after task decomposition, determining who coordinates execution, passes results, and decides which agent to call next still requires an orchestration mechanism.

Anthropic recently introduced a new implementation: Claude generates an orchestration program based on task requirements. This program is responsible for launching sub-agents, bridging different stages, processing return results, and reporting execution status back to the main agent. Consequently, coordination work that previously required continuous participation from the main agent can now be handled by background programs.

On October 9, Anthropic launched Dynamic Workflows for Claude Managed Agents, currently in Beta. On October 12, at a workshop during the AI Engineer New York 2026 conference, Anthropic engineers CJ Avilla and Harrison Stall provided further insights into this mechanism.

During the conference presentation, Anthropic engineers used the evolution of Unix and Linux projects—from individual development to large-scale collaboration—to illustrate how task organization and coordination become bottlenecks as more agents participate in software development. Dynamic Workflows represent Anthropic's attempt to address this challenge.

Writing Multi-Agent Execution Plans into Programs

When developers apply multi-agent systems to real-world projects, they often find that distributing tasks is just the first step; the harder part is stitching the entire process together. For example, having the main agent dispatch several sub-agents to research information simultaneously is not difficult. The trouble arises when every result must return to the main conversation, where the main agent processes them one by one and arranges subsequent tasks. As the number of tasks grows, the context easily becomes cluttered with intermediate results.

In the traditional model where the main agent directly calls sub-agents, the main agent is responsible for dispatching tasks, reading return results, and deciding how to proceed. While sub-agents can work in parallel, subsequent coordination is still driven by the main agent.

Dynamic Workflows move some coordination logic into programs. Claude generates an orchestration program based on task requirements, defining how tasks are split, what stages exist, and how different agents' work connects. Subsequently, this program executes on the server in the background, handling agent launches, passing intermediate results, and advancing subsequent tasks based on execution status.

The orchestration program here is not merely a task list for the model to read. It contains actual execution logic, such as launching multiple agents in parallel, using results from previous stages as inputs for the next, deciding whether to re-execute a task based on check results, and choosing to continue or terminate if a sub-agent fails.

Compared to traditional sub-agent delegation, the key difference lies in who determines the subsequent execution steps. Previously, after a sub-agent returned results, the main agent often needed another round of reasoning to decide the next action. Dynamic Workflows allow the orchestration program to continue execution directly based on returned data. The main agent does not need to participate in every handoff; it can handle other matters while the background workflow runs and review final results upon completion.

In the official documentation for Multiagent Orchestration on the Claude Platform, Anthropic specifically compares traditional Subagents with Dynamic Workflows: the former relies on the main agent to gradually determine subsequent operations based on sub-task return results; the latter delegates logic such as loops, conditional branches, and result passing to the orchestration program. Intermediate data can be stored in program variables, eliminating the need to return to the main agent for reprocessing each time.

A live demonstration at the conference used a stock watchlist scanning task: Stage one assigned different stocks to agents with independent contexts; subsequent stages checked scan results and generated reports. This example illustrated how workflows connect distributed execution, centralized review, and final aggregation.

Developers can still constrain the agents involved in tasks. Official support includes predefined agents and inline agents defined on the fly: the former uses pre-set models, prompts, and tools; the latter is created per current task, inheriting the main agent's model and related tool configurations. Developers can disable temporary creation capabilities, allowing workflows to call only agents from a specified whitelist. Thus, dynamic generation of execution plans and pre-configured specialized agents can coexist. For instance, a developer might retain a dedicated review agent and let Claude decide when to invoke it.

Dynamic Workflows reduce the need for developers to pre-design task execution paths.

If a simple task triggers a large number of Agents, how can we avoid excessive invocation? How do we control the costs of multi-Agent systems? These are concerns shared by many developers.

According to Anthropic’s official documentation, a single dynamic workflow can launch up to 1,000 Agents cumulatively, but the limit for concurrently running Agent threads is 64. The default maximum runtime for a single workflow is 24 hours. This means that the 1,000 figure represents the total number of Agents launched over the entire execution cycle, not the number of Agents Claude can schedule simultaneously. It also does not imply that the system can stably handle multi-Agent tasks at this scale.

These limits define the execution boundaries of dynamic workflows, but Anthropic has not yet provided a universal answer regarding how many Agents should be launched for a specific task. During the live Q&A session, Stall mentioned that currently, the number of Agents is primarily controlled through evaluations and conservative default settings. For more complex tasks, it is often necessary to explicitly guide the model to increase parallelism. He also noted that the model is unaware of its available budget during runtime; however, developers can set session budgets.

Costs also require case-by-case analysis. In a live demonstration involving stock watchlist scanning, Avilla stated that dynamic workflows cost more than single-Agent solutions but can uncover more details.

Regarding cost control, Managed Agents provide a session-level budget mechanism. The platform accumulates costs based on public pricing rates according to consumption metrics such as model tokens, web searches, and session runtime. Once the budget cap is reached, the system stops issuing new model requests, and the task pauses. Developers can resume execution by adjusting the budget.

However, this is not a hard switch that immediately interrupts all computations. Model requests already in flight will still complete. When multiple Agents run in parallel, final consumption may exceed the budget cap. Additionally, since budgets are calculated using public list prices, the recorded totals may differ from the actual amounts billed to enterprises.

This explains why “having the main Agent read fewer intermediate results” does not directly translate to “overall lower costs”: every participating Agent incurs inference costs, and additional review steps also require computational resources.

Can Workflows Improve Themselves?

In the live Q&A, another noteworthy question arose: If a dynamic workflow needs to be executed repeatedly, can it improve itself based on previous run results to complete tasks faster and at lower cost?

An audience member asked using the stock watchlist scanning example: If the system discovers that the current scanning model performs poorly, can it proactively switch models or adjust the original execution flow during the next scheduled run?

Stall clarified that Dynamic Workflows currently lack built-in self-improvement capabilities. However, he and Avilla mentioned two potential approaches for improvement: Hill-climbing and the Dreaming feature currently under research by Anthropic.

Dreaming can be understood as a memory consolidation mechanism for Agent historical experiences. According to the Anthropic Dreams official documentation, it reads existing memory banks and past session records, merges redundant information, replaces outdated or contradictory content, and extracts new insights from historical sessions to generate a reorganized memory bank.

This process does not directly overwrite the original memory bank. Dreaming generates an independent new memory bank, which developers can inspect before deciding whether to use it in subsequent sessions. Currently, this feature is in the research preview stage and requires access approval.

Avilla explained during the session that Dreaming helps Agents further refine and solidify experiences from previous sessions. For workflows that need to run repeatedly, this gives developers the opportunity to organize problems discovered, information accumulated, and effective handling methods from past executions into memories that future tasks can reference. The Managed Agents memory mechanism allows developers to attach memory banks to new sessions, enabling Agents to carry relevant information across different sessions.

However, organizing memory and optimizing workflows are distinct concepts. Dreaming itself does not determine how many Agents to launch, which models to use, or automatically modify the orchestration program generated by Claude. Hill-climbing offers another approach: attempting to find better configurations or execution strategies through repeated evaluation and local adjustments. Nevertheless, Anthropic did not announce a complete implementation integrating these mechanisms into Dynamic Workflows during this event.

Therefore, while Claude can currently dynamically generate multi-Agent orchestration programs based on tasks, workflows cannot yet automatically form a complete improvement loop of “execution, evaluation, modification, and re-verification.” To achieve continuous optimization in repetitive tasks, developers still need to design evaluation metrics, record run results, and decide how to apply historical experiences to the next execution.

Agents Can Relay Tasks, But Cannot Freely “Group Chat”

In dynamic workflows, although sub-Agents have independent conversation contexts, they are not isolated from each other. According to the Anthropic Workflow Runs official documentation, they can pass results via the orchestration program and exchange information through the shared file system within the session sandbox.

Specifically, there are two primary methods for information transfer. The first is handled by the orchestration program: after one Agent completes a task and returns results, the program can pass relevant content as input to the next Agent. For example, one Agent might analyze code, and its analysis results could then be passed to another Agent for review. The second method uses the shared file system: different Agents can write intermediate artifacts to files for other Agents to read and use.

However, this collaboration style differs from direct messaging between Agents. Stall explained during the live Q&A that developers currently cannot use the API to directly instruct a sub-Agent in a workflow to send messages to another sub-Agent. Task handoffs between Agents rely primarily on definitions within the orchestration program.

This also differs from how traditional subagents interact. Threads for conventional subagents can be retained, allowing the main agent to continue sending follow-up messages to them; however, threads for subagents within dynamic workflows cannot accept appended messages in the same way and are archived once the workflow run concludes.

The shared file system introduces another engineering challenge: context isolation does not equate to file access isolation. Although each agent’s conversation history is independent, they all have access to shared files within the same session environment. Consequently, when handling code, configuration files, or sensitive data, developers must still account for file overwrites, conflicts arising from shared state, and varying access permissions across different agents.

For multi-stage tasks requiring a "analyze first, then review, finally summarize" approach, dynamic workflows can already facilitate task handoffs programmatically. However, if you want multiple agents to engage in continuous discussion and send messages to one another at any time, this orchestration mechanism should not be directly equated with a multi-agent network that supports free-form communication.

Program Execution Completion Does Not Guarantee Task Acceptance

The fact that multiple agents can relay tasks according to a defined flow does not mean every step will complete successfully. For long-running tasks, developers need to distinguish between two concepts: does the end of the workflow signify that the task is truly finished?

Regarding the reliability of long-running tasks, there is a critical point in the official documentation: a workflow returning completed only indicates that program execution has ended. Even if some thread tasks fail, or certain threads were never created, the entire run may still conclude with a completed status.

The official documentation further distinguishes between program errors and incomplete task results. If the workflow code fails to execute, or if a subagent’s failure is not handled by the workflow, the run may terminate with a program_error. However, if the orchestration program catches the failure and continues running, it may ultimately still return completed. Therefore, the program’s ability to handle errors does not imply that the business task has succeeded.

This means that a batch review task might generate a summary report while some materials remain unread due to failures. If an application only checks the final status, it risks treating an incomplete report as evidence that all tasks are done.

Thus, acceptance validation cannot rely solely on status codes; it must also verify task coverage, failed items, and key outcomes. For coding tasks, this involves combining test and build results; for document reviews, it requires maintaining a list of unprocessed materials and clearly indicating which conclusions have been verified.

The orchestration program generated by the model itself may encounter errors, including execution failures, timeouts, and exceeding agent count limits. The same work item might spawn new threads upon retry. If tools write data to external systems, developers must also handle duplicate calls to prevent submitting the same record multiple times during retries. Specific business requirements necessitate robust validation and recovery mechanisms that cannot be overlooked.

Dynamic Workflows delegate part of the scheduling originally handled by the main agent to programmatic execution, enabling Claude to temporarily organize multi-agent collaboration based on task requirements. Whether this approach yields better results in real-world projects depends on metrics such as task completion rates, failure recovery capabilities, and overall execution costs. Particularly as the number of agents increases, verifying intermediate results, managing shared state, and controlling computational overhead remain challenges that developers must address.

References:

https://platform.claude.com/docs/en/managed-agents/multiagent-orchestration

https://platform.claude.com/docs/en/managed-agents/workflow-runs

https://www.latent.space/p/claude-dynamic-workflows