Claude has started writing its own programs to manage Agents: Anthropic unveils the new-generation multi-agent orchestration architecture
In a multi-agent system, tasks can be assigned to different agents for parallel completion. However, after task splitting, a set of orchestration mechanism is still required to clarify who is responsible for coordinating execution, delivering results, and deciding which agent to invoke in the next step.
Anthropic has recently proposed a new implementation approach: Claude generates an orchestration program based on task requirements, which is responsible for launching sub-agents, connecting different stages, processing returned results, and then sending the execution status back to the main agent. Part of the coordination work that previously required continuous participation of the main agent can thus be completed by background programs.
On October 9, Anthropic launched Dynamic Workflows for Claude Managed Agents, which is currently in Beta stage. On October 12, at the workshop of AI Engineer New York 2026, Anthropic technicians CJ Avilla and Harrison Stall further introduced this mechanism.
In the conference sharing, Anthropic engineers used the evolution process of Unix and Linux projects from individual development to large-scale collaboration to illustrate that as more and more agents participate in software development, task organization and coordination itself will become a bottleneck. Dynamic Workflows is the new mechanism Anthropic has tried for this purpose.
1
Write multi-agent execution plans into programs
When developers apply multi-agents to real projects, they often find that assigning tasks is only the first step, and the more labor-consuming part is to connect the whole process. For example, it is not difficult for the main agent to assign several sub-agents to search for materials at the same time. The trouble is that each result has to be returned to the main conversation, and then processed one by one by the main agent to arrange subsequent tasks. When there are too many tasks, the context is easily filled with intermediate results.
In the mode where the main agent directly invokes sub-agents, the main agent is responsible for distributing tasks, reading returned results, and then deciding how to proceed. Sub-agents can work in parallel, but subsequent coordination is still advanced by the main agent.
Dynamic Workflows, by contrast, writes part of the coordination logic into the program. Claude generates an orchestration program according to task requirements, determining how tasks are split, which stages they are divided into, and how the work of different agents is connected. Then this program is executed in the background by the server, responsible for launching agents, transmitting intermediate results, and advancing subsequent tasks according to the execution status.
The orchestration program here is not a task list for the model to read. It contains actual execution logic, such as launching multiple agents in parallel, taking the result of the previous stage as the input of the next stage, deciding whether to re-execute a certain task according to the inspection result, and choosing to continue or terminate when a sub-agent fails.
Compared with the traditional sub-agent delegation method, the difference lies in who decides the subsequent execution steps. Previously, after the sub-agent returns the result, the main agent often needs to perform another reasoning to decide the next operation. Dynamic Workflows allows the orchestration program to continue executing directly based on the returned data. The main agent does not need to participate in every task handover, can handle other things while the background workflow is running, and view the final result after the operation ends.
In the official Multiagent orchestration documentation of Claude Platform (https://platform.claude.com/docs/en/managed-agents/multiagent-orchestration), Anthropic made a special comparison between traditional Subagents and Dynamic Workflows: the former is that the main agent gradually determines subsequent operations according to the returned results of subtasks; the latter hands over logics such as loops, conditional branches and result transmission to the orchestration program for execution, and intermediate data can be stored in program variables without needing to be returned to the main agent for reprocessing every time.
The conference site used a stock watchlist scanning task for demonstration: in the first stage, different stocks are assigned to agents with independent contexts, and in subsequent stages, the scanning results are checked and then a report is generated. This example shows how the workflow connects decentralized execution, centralized review and final aggregation.
Developers can still constrain the agents participating in tasks. The official supports pre-defined agents and temporarily defined inline agents: the former uses pre-set models, prompts and tools; the latter is created according to the current task and inherits the model and related tool configurations of the main agent. Developers can turn off the temporary creation capability and only allow the workflow to invoke agents in the specified list. Therefore, dynamically generating execution plans and pre-configuring professional agents can coexist. For example, developers can reserve a dedicated review agent, and then let Claude decide when to invoke it.
Dynamic Workflows reduces the work of developers to pre-design task execution paths, but does not remove developers' constraints on system behavior. Which agents can participate, which tools can be invoked, how much cost is allowed, and what results count as task completion still need to be determined by developers through configuration, permission policies and business verification mechanisms.
2
The cumulative upper limit is 1000 agents, and the budget also has execution boundaries
If a simple task also launches a large number of agents, how to avoid excessive invocation? How to control the cost of multi-agents? This is a concern of many developers.
According to Anthropic's official documentation, a single dynamic workflow can launch up to 1000 agents in total, but the upper limit of concurrently running agent threads is 64, and a single workflow runs for a maximum of 24 hours by default. That is to say, 1000 is the total number of agents launched during the entire operation cycle, which does not mean that Claude can schedule 1000 agents at the same time, nor does it mean that it can stably complete multi-agent tasks of such a scale.
These restrictions clarify the execution boundaries of Dynamic Workflows, but Anthropic has not yet given a general answer to how many agents should be launched for a certain task. In the on-site Q&A, Stall mentioned that currently the number of agents is mainly controlled by evaluation and relatively low default settings; for more complex tasks, it is usually necessary to explicitly guide the model to increase parallelism. He also said that the model does not know its available budget at runtime, and developers can set a session budget.
The cost also needs to be analyzed specifically. In the on-site demonstration of stock watchlist scanning, Avilla said that Dynamic Workflows costs more than the single-agent solution, but can also discover more details.
In terms of cost control, Managed Agents provides a session-level budget mechanism. The platform accumulates costs according to public prices based on consumption such as model tokens, web search and session running time. After reaching the budget upper limit, the system will stop sending new model requests, and the task will be suspended; developers can resume execution by adjusting the budget.
However, this is not a hard switch that can immediately interrupt all calculations. The model requests that have been sent will still be completed, and when multiple agents run in parallel, the final consumption may exceed the budget upper limit. In addition, since the budget is calculated according to the public price, its statistical result may also be different from the actual settlement amount of the enterprise.
This also explains why "the main agent reads fewer intermediate results" cannot directly lead to "lower overall cost": every agent participating in the work will generate inference consumption, and additional review links also require computing resources.
3
Can workflows get better on their own?
In the on-site Q&A (https://www.latent.space/), there is another noteworthy question: if a dynamic workflow needs to be executed repeatedly, can it continuously improve itself according to previous operation results to make the task completed faster and at lower cost?
An audience member took the stock watchlist scanning as an example to ask: if the system finds that the currently used scanning model does not perform well, can it actively replace the model or adjust the original execution process in the next scheduled run?
Stall clearly stated that Dynamic Workflows does not currently have such a built-in self-improvement capability. However, he and Avilla mentioned two possible improvement methods: Hill-climbing and the Dreaming function that Anthropic is researching.
Dreaming can be understood as a memory sorting mechanism oriented to the historical experience of agents. According to the definition in Anthropic Dreams official documentation (https://platform.claude.com/docs/en/managed-agents/dreams), it will read the existing memory base and past session records, merge duplicate information, replace outdated or contradictory content, extract new experience from historical sessions, and finally generate a reorganized memory base.
This process will not directly overwrite the original memory base. Dreaming will generate an independent new memory base, and developers can check its content before deciding whether to use it for subsequent sessions. Currently, this function is still in the research preview stage, and access permission is required for use.
Avilla explained on site that Dreaming can help agents further extract and solidify the experience in previous sessions. For workflows that need to run repeatedly, this means that developers have the opportunity to sort out the problems found in the past execution process, accumulated information and effective processing methods into memories that can be referenced by subsequent tasks. The memory mechanism of Managed Agents (https://platform.claude.com/docs/en/managed-agents/memory) allows developers to attach the memory base to new sessions, so that agents can continue related information across different sessions.
However, sorting out memories and optimizing workflows are still two different things. Dreaming itself will not judge how many agents to launch and what model to use, nor will it automatically modify the orchestration program generated by Claude. Hill-climbing provides another idea: try to find a better configuration or execution strategy through repeated evaluation and local adjustment. However, Anthropic did not announce the complete implementation of integrating these mechanisms into Dynamic Workflows this time.
Therefore, Claude can already dynamically generate multi-agent orchestration programs according to tasks, but workflows cannot automatically form a complete improvement cycle of "execution, evaluation, modification, and re-verification". To make it continuously optimize in repeated tasks, developers still need to design evaluation indicators, record operation results, and decide how to apply historical experience to the next execution.
4
Agents can relay, but cannot freely "group chat"
In Dynamic Workflows, although each sub-agent has an independent conversation context, they are not isolated from each other. According to Anthropic's Workflow Runs official documentation (https://platform.claude.com/docs/en/managed-agents/workflow-runs), they can not only pass results through the orchestration program, but also exchange information with the help of the shared file system in the session sandbox.
Specifically, there are two main ways of information transmission. The first one is the responsibility of the orchestration program: after an agent completes the task and returns the result, the program can take the relevant content as input and hand it over to the next agent. For example, one agent first analyzes the code, and then the analysis result is handed over to another agent for review. The second one is completed through the shared file system: different agents can write intermediate products into files for other agents to read and use.
However, this collaboration method is still different from agents directly sending messages to each other. Stall explained in the on-site Q&A that developers currently cannot directly require a sub-agent in the workflow to send a message to another sub-agent through the API. The task connection between agents mainly relies on the execution logic and shared data defined by the orchestration program.
This is also different from the interaction mode of ordinary Subagents. The thread of traditional sub-agents can be retained, and the main agent can continue to send subsequent messages to it; while the sub-agent threads in Dynamic Workflows cannot append messages in the same way, and will be archived when the workflow operation ends.
The shared file system also brings another engineering problem: context isolation does not equal file access isolation. Although the conversation history of each agent is independent of each other, they can access the shared files in the same session environment. Therefore, when processing code, configuration files or sensitive data, developers still need to consider file overwriting, shared state conflicts, and access permissions of different agents.
For multi-stage tasks that require "first analysis, then review, and finally aggregation", Dynamic Workflows can already complete task relay through programs. But if you want multiple agents to continuously discuss with each other and send messages to each other at any time, this orchestration mechanism cannot be directly equated with a multi-agent network that supports free communication.
5
After the program is executed, the task still needs acceptance inspection
The fact that multiple agents can relay according to the process does not mean that every step can be completed smoothly. For long tasks, developers also need to clarify one thing: when the workflow ends, does it mean that the task is completed?
Regarding the reliability of long tasks, there is one point in the official documentation that requires special attention: the workflow returns completed, which only means that the program execution is over. Even if the task of some threads fails, or a certain thread fails to be created, the entire operation may still end with completed.
The official also distinguishes between program errors and incomplete task results. If the workflow code execution fails, or the failure of a certain sub-agent is not handled by the workflow, the operation may end with program_error. But if the orchestration program catches the failure and continues to run, it may still return completed in the end. Therefore, the fact that the program can handle errors does not mean that the business task has been successful.
This means that a batch review task may have generated an aggregated report, but some materials have not been successfully read. If the application only checks the final status, it may regard an incomplete report as the completion of all tasks.
Therefore, acceptance inspection cannot only look at the status, but also check the task coverage, failed items and key results. Code tasks can be combined with test and build results; document review should retain the list of unprocessed materials, and clarify which conclusions have been reviewed.
The model-generated orchestration program itself may also have errors, including execution failure, timeout and exceeding the agent quantity limit. The same job may also create new threads due to retries. If the tool writes data to an external system, developers also need to deal with the problem of repeated invocation to avoid resubmitting the same record multiple times in one retry. The verification and recovery mechanisms required by specific businesses are still indispensable.
Dynamic Workflows hands over part of the scheduling work that was originally the responsibility of the main agent to the program for execution, allowing Claude to temporarily organize multi-agent collaboration according to task requirements. As for whether this method can achieve better results in real projects, it still needs to measure the task completion rate, failure recovery capability and overall execution cost. Especially when the number of agents continues to increase, how to verify intermediate results, manage shared state and control computing overhead is still a problem that developers need to solve.
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
This article is from the WeChat official account "InfoQ" (ID: infoqchina), written by Lin Qibei and Cai Fangfang, authorized for release by 36Kr.