Anthropic Dynamic Workflows: A New Paradigm for Claude Multi-Agent Orchestration

At AI Engineer New York 2026, Anthropic team members CJ Avilla and Harrison Stall shared a newly released feature—dynamic workflows, or "flows" as the speakers repeatedly called them. The feature was defined as "a whole new way to orchestrate multi-agent systems, built for the most ambitious workloads."

From Unix to Agents: Lessons from Organizational Structure

Avilla and Stall opened with a deliberately pointed analogy. They started with Ken Thompson building the original Unix operating system, then traced Linux's evolution from a project run by Linus Torvalds alone into a multi-layered hierarchy of trusted maintainers. The parallel points to a core insight: for agents to complete the ambitious projects Anthropic envisions, they need the same level of organizational structure as an operating system project.

Avilla voiced the real pain many developers feel: "A lot of us who are orchestrating and managing lots of agents might be starting to feel the pressure of becoming the bottleneck, or even the breaking point—tons of agents contributing tons of PRs, and we're sitting in GitHub trying to approve those PRs and make sure everything works the way we expect."

This problem isn't unique to Anthropic. As AI coding tools proliferate, developers are shifting from writing code to reviewing AI-generated code—the role has changed, but the bottleneck feeling has only intensified. Dynamic workflows are a direct response to that pain point.

The Unix maintainer model refers to the layered trust structure used by large open-source projects like the Linux kernel: Linus Torvalds as the top maintainer, with subsystem maintainers below him (networking, filesystems, etc.), then maintainers for individual drivers and modules, and at the bottom, developers contributing patches. Every patch must pass through tiered review before merging into the mainline. What allows this model to support tens of thousands of contributors collaborating over decades is layered responsibility and transitive trust: top-level maintainers don't need to review every line of code—they just trust that lower-level maintainers have already vetted it. The speakers use this to analogize multi-agent orchestration—a lead agent doesn't need to handle every subtask itself, it just needs to orchestrate, trust, and aggregate the output of lower-level agents. This also explains why "letting Claude decide the topology" is a natural progression: the developer's role degrades from "hardcoding coordination logic" to "defining goals and verification boundaries," similar to how Linus degraded from writing code to being a merge maintainer.

How Dynamic Workflows Operate

According to the two speakers, the concept of dynamic workflows originated from the "a harness for every task" idea in Claude Code, but flows can run over far longer timescales than a single agent or a fixed group of agents. The core idea is: let Claude choose how the agents are organized.

Stall explained: "Flows are essentially the next generation of multi-agent orchestration—you can let Claude fully orchestrate its own multi-agent topology."

The mechanism is: a lead agent first lays out a plan for the task, then Claude writes an orchestration program that launches agents, collects results, and manages the flow of information. Unlike earlier approaches where developers had to configure a coordinator and roster of sub-agents, dynamic workflows let Claude decide on its own how to divide and orchestrate the work.

"Across many different stages of multi-agent orchestration, it can complete discrete, verifiable units of work, and you don't have to manage any of the interconnections between those stages," Stall said. Avilla added, however, that users can still pass in pre-configured expert sub-agents in the agent configuration.

The feature is currently available in Claude Console—the interface where developers access Claude through the API.

Multi-agent orchestration refers to using multiple LLM-powered agents to collaborate on tasks that a single agent struggles with, typically involving task decomposition, role assignment, result aggregation, and conflict resolution. Common topologies include: coordinator-worker (one lead agent dispatches tasks to sub-agents), pipeline (agents process serially in stages), and debate/voting (multiple agents solve independently and then cross-validate). Previously, developers had to manually choose a topology and write scheduling code (e.g., with frameworks like LangGraph or AutoGen). Dynamic workflows differ by handing "choosing the topology" itself to Claude: the lead agent plans first, then Claude generates an orchestration program (essentially scheduling code), which instantiates sub-agents on demand at runtime. This means the topology is dynamically generated at runtime rather than statically configured at development time—so the same flow can unfold into completely different collaboration graphs depending on the input.

Stock Monitoring Example: Validating the Pattern in a Simple Scenario

The speakers demonstrated a relatively simple stock watchlist scanner workflow. While far less ambitious than the grand projects Anthropic encourages, it clearly illustrates the basic pattern: a scanning stage distributes individual tickers to agents with isolated contexts, followed by a review stage that checks the findings and generates a report.

The value of this example is letting developers intuitively grasp the "divide and conquer" logic of flows—each sub-agent works in an isolated context, avoiding information contamination, with the lead agent aggregating the results at the end.

Budget Control and the Boundaries of Self-Improvement

The audience Q&A surfaced several practical concerns worth noting.

On how Claude decides how many agents a task needs, and whether a simple stock scan might trigger hundreds of sub-agents, Stall's answer was: "The answer is really evals and lower defaults." He noted that ambitious tasks usually require explicitly encouraging more parallelism.

Token budget control is a persistent concern. Someone asked whether the lead agent knows how much money it has available. Stall answered that the model doesn't know its budget at runtime, but developers can set a session budget. He also mentioned that telling the model about the budget might make the agent "a little anxious," drawing laughter from the audience.

On how to make repeatedly-run flows cheaper and more efficient over time, Avilla suggested using another newer feature: dreaming. According to the documentation, dreaming is a research preview feature that "reads existing memory stores and past session records, then generates a new, reorganized memory store," merging duplicates, replacing outdated or contradictory entries, and surfacing new insights. Avilla described dreaming in the flow context as being able to "crystallize and essentially improve the memory stores associated with those sessions."

As for whether a stock watchlist flow could self-improve—for instance, recognizing that the scanning model is insufficient and changing the next scheduled run—Stall said this isn't built in, but hill-climbing plus dreaming could be combined to improve the loop.

Test-time compute refers to investing more compute at inference time rather than training time to improve model performance. Typical techniques include chain-of-thought, self-consistency sampling (sampling multiple times and voting), best-of-N, and tree search. The core hypothesis is that for hard problems, letting the model "think longer" or "try more times" can match the effect of scaling up the model. Dynamic workflows extend this idea to the multi-agent level—rather than having a single model think more, multiple agents explore different paths in parallel within isolated contexts, with a lead agent aggregating their outputs. This "parallel sampling + aggregation" structure is naturally suited to tasks with large search spaces where a single pass easily misses things (such as full-codebase audits or literature reviews). But the cost is that token consumption grows roughly linearly—or even superlinearly—with the number of agents. So the benefit of test-time compute must be weighed against cost, which is why the speakers repeatedly emphasized budget control and dreaming-based optimization.

Observability and Cost Trade-offs

On visibility into sub-agent behavior, Avilla confirmed that developers can always inspect things through the graphical features in Claude Console. "You can see what the lead agent actually passed to the sub-agents, you can view the payload here, and dive deep into what actually happened at each transition in the whole graph."

Can sub-agents communicate directly with each other? Stall said agents share a filesystem and can exchange information through it, but developers cannot directly instruct one workflow sub-agent to send a message to another via the API.

On cost, Avilla stated clearly in a comparison that flows are "much more expensive," but also "much more effective at finding all the details." This is a classic capability-cost trade-off: a single agent may miss details, while multi-agent parallel scanning can cover more comprehensive information.

The Possibility of Grand Scientific Problems

Someone asked whether dynamic workflows could support large-scale scientific research projects, citing OpenAI's recent claim about a proof related to the Navier-Stokes Millennium Prize problem. Stall didn't reveal specifics about how Anthropic would compute large scientific problems, but said enabling ordinary users to tackle these problems is exactly their goal.

"Flows are basically a way to throw test-time compute at hard problems and get more capability out of the model faster," he said. "We think that especially as an API service, unleashing that power is our first step toward making this kind of discovery or scientific progress broadly achievable for everyone."

This vision deserves to be taken seriously. Test-time compute has become an important path for improving model capabilities, and flows are essentially a way to systematically scale test-time compute at the multi-agent level. If this path works, solving complex scientific problems in the future may no longer be the exclusive domain of big labs.

But between a stock scanner and a Navier-Stokes proof, the gap is not trivial. Current flows still have clear limitations in budget control, self-improvement, and inter-agent communication, and there's still a considerable distance to go before they can support grand scientific projects. Anthropic positioning it as "the first step" is a pragmatic framing.

One-line Summary

Anthropic releases dynamic workflows (flows), letting Claude orchestrate multi-agent topologies on its own—trading higher cost for greater capability.

Paragraph Summary

At AI Engineer New York 2026, Anthropic introduced dynamic workflows (flows), an orchestration approach that lets Claude design its own multi-agent topology. The speakers drew an analogy to the layered maintainer model of Unix and Linux, pointing out that developers are becoming the review bottleneck for large volumes of AI-generated PRs—flows are the response: a lead agent plans first, then Claude generates an orchestration program that dynamically launches sub-agents and collects results. The feature is currently available in Claude Console via API. The Q&A revealed key boundaries: the model doesn't know its own budget at runtime, but developers can set a session budget; sub-agents communicate through a shared filesystem, and direct API control of inter-agent messaging isn't supported; costs are far higher than a single agent but coverage is more comprehensive; dreaming can be used to optimize repeated runs. Anthropic positions it as a first step toward throwing test-time compute at hard problems and enabling the public to participate in scientific discovery.