At the AI Engineer NYC conference, Anthropic presented how to orchestrate its Claude Managed Agents and highlighted a new feature called dynamic workflows, or simply flows. Defined as a new type of multiagent orchestration for ambitious workloads, the feature aims to address bottlenecks that arise when managing many agents.
SynthePulse Insight · AI deep reading
Version 1 · 1 source
At AI Engineer New York 2026, Anthropic introduced dynamic workflows (flows): letting Claude decide the multi-agent topology itself and take on grander tasks. But costs run far higher than single-agent approaches, and budget control, sub-agent communication, and self-improvement all still have clear boundaries.
Anthropic released a new feature last Friday called dynamic workflows (flows for short), introduced by CJ Avilla and Harrison Stall at a workshop at AI Engineer New York 2026. Both are Members of Technical Staff at Anthropic. flows is defined as "a new kind of multi-agent orchestration, built for the most ambitious workloads."
Its origin lies in the concept in Claude Code of "a harness for every task." Stall called flows "the next version of multi-agent orchestration," allowing Claude to fully orchestrate its own multi-agent topology. The specific mechanism is: the lead agent first lays out a plan to complete the task, and Claude then writes an orchestration program to launch agents, collect results, and manage the flow of information.
Unlike the earlier Claude Managed Agents, which required developers to configure the coordinator and the roster of sub-agents, dynamic workflows lets Claude decide on its own how to divide and orchestrate the work. Avilla said users can still pass in pre-configured expert sub-agents in the agent config. The feature is available in the Claude Console, the interface through which developers access Claude via API, and also where Claude Managed Agents lives.
The stock watchlist scan workflow in the demo is divided into two stages: the scan stage distributes each stock to agents with isolated contexts, and the subsequent review stage checks the findings and generates a report. Anthropic used it to illustrate the basic pattern, even though it is still far from the grand projects the company officially encourages.
This demo also exposed the visibility problem of orchestration. Avilla said developers can inspect sub-agent actions through a graphical feature within the Claude Console, including the payload the lead agent passes to sub-agents, so they can understand what actually happens at every transition in the whole graph.
As for how sub-agents collaborate, Stall said they share a file system and exchange information through it, but developers cannot directly instruct one workflow sub-agent to message another via API.
In the stock watchlist scan comparison, Avilla said flows cost "much more" than a single-agent approach, but was "much more effective" at finding all the details. This is a qualitative statement, with no specific figures given.
Budget control was one of the focal points of the live Q&A. Stall said the model does not know its own budget at runtime, but developers can set a session budget. He also mentioned that telling the model its budget might make the agent "a little anxious" — a live remark lacking further explanation.
As for how many agents a task needs, Stall's answer was "the answer is really evals and lower defaults," and he said grand tasks usually require explicitly encouraging more parallelism. As for whether simple tasks (such as a stock scan) would trigger hundreds of sub-agents, no clear upper limit was given on site.
Someone asked whether the stock watchlist workflow could improve itself, for example by recognizing that the scan model was insufficient and changing the next planned run. Stall said this is not a built-in capability, but he and Avilla suggested that hill-climbing and dreaming could be used to improve the loop.
The documentation defines "dreaming" as a research preview feature: it reads existing memory stores and past session records, generates a reorganized memory store, merges duplicates, replaces outdated or contradictory entries, and surfaces new insights. In the context of flow, Avilla described it as being able to "crystallize and basically improve the memory stores associated with those sessions."
What needs to be distinguished is this: dreaming is still currently a research preview feature, and whether flows can become cheaper and more efficient through it over the long term has not yet been verified.
Someone on site asked whether dynamic workflows could support large-scale scientific research projects, and mentioned OpenAI's recent proof concerning the Navier–Stokes Millennium Prize problem. Stall did not give specifics on how Anthropic would compute large scientific problems, but said that enabling ordinary users to handle such problems is their goal.
His phrasing was: flows is essentially a way to direct test-time compute at hard problems and get more capability out of the model faster; as an API service, unlocking this capability is the first step toward making this kind of discovery or scientific progress broadly doable by the general public.
Therefore, exactly how grand a task flows can take on, and whether it can enable the general public to broadly carry out this kind of scientific discovery, currently exist only as goal-level statements, with no verifiable results.
The facts in this article come from Latent Space's report on a workshop at AI Engineer New York 2026 (article_id 22109). Among these, the product release, definition, mechanism, Console availability, demo structure, and the documentation definition of dreaming are confirmed information; the statements by Stall and Avilla about orchestration capability, sub-agent configuration, budget, visibility, communication methods, and self-improvement are on-site remarks and are treated as source claims. The cost being "much more" and "much more effective" are qualitative comparisons with no specific figures. The statements related to grand tasks and scientific discovery are goal statements and have not been verified.
flows hands the decision over the multi-agent topology from developers to Claude. The direction is clear, but the boundaries are equally clear: costs run far higher than single-agent approaches, the model does not know its budget at runtime, sub-agents cannot message each other directly via API, and self-improvement is not built in. It looks more like an orchestration layer that directs test-time compute at hard problems than a finished product that has already solved cost and controllability.
Secondary coverage
This article also covers this event; its overall headline is not the event headline.