Claude Dynamic Workflows Make Orchestration, Not the Single Agent, the Unit of Work

Start with the facts we actually have. The feature surfaced publicly in an Anthropic workshop on orchestrating Claude Managed Agents at AI Engineer New York 2026. It was presented by CJ Avilla and Harrison Stall, both Members of Technical Staff at Anthropic. The feature name is dynamic workflows, the working nickname is flows, and the official description is "a new type of multiagent orchestration, built for your most ambitious workloads."

That is a short list. You should resist anyone, including us, who claims to know the full spec from a conference workshop summary. What the list does give you is the positioning, and positioning is a choice a company makes on purpose.

Notice what Anthropic did not say. It did not lead with a benchmark, a new model, or a context-window number. It led with coordination. That fits a pattern this publication calls The Harness Hypothesis: the value in AI isn't in the model, it's in the harness that connects the model to the world. For most of the agent era, the harness question was about tools: which systems can one agent touch? Flows move the question up a level. Which agents run, in what structure, and who decides?

Here's the plain-language version, Feynman-style. A single agent is one capable employee. A hand-wired multi-agent setup is a group of employees passing sticky notes down a hallway. Orchestration is hiring a manager whose only job is deciding who does what, when, and what happens to the work afterward. Anthropic is now offering that manager as a built-in part of the platform.

• What's confirmed: the name, the presenters, the venue, the timing, and the one-sentence definition.
• What's interpretation: everything about how flows schedule, parallelize, or recover from failure. Treat those parts of any coverage, including this one, as analysis until you've seen the documentation yourself.

The most revealing detail in the workshop coverage is not a feature. It's a history lesson. According to Latent Space's write-up, Avilla and Stall opened by invoking operating system projects of the past, starting with the work of Ken Thompson.

Why would a team launching an agent feature start with Unix-era history? Because operating systems solved a problem that looks a lot like the one multi-agent users have now. Early computers ran one job at a time. Operating systems introduced the idea that many programs could share one machine, with a scheduler deciding who runs, a way to pass output from one program to the next, and rules for what happens when something crashes.

Our reading, and it's analysis rather than anything the presenters are quoted saying: Anthropic wants you to think of flows as a scheduler for agents. The individual Claude agent is the process. The flow is the thing that starts processes, feeds them inputs, collects their outputs, and decides the next step.

That framing sets expectations in two directions, and you'll want to hold both.

• The ambitious direction. Operating systems are what turned single-purpose machines into general-purpose ones. If Anthropic is reaching for that comparison, it is claiming flows will make Managed Agents a platform for long, many-part jobs rather than a tool for single tasks.
• The sobering direction. Operating systems are also where the hardest bugs live: race conditions, deadlocks, processes that hang forever, one crashing program taking others down with it. If flows are an agent scheduler, you inherit the scheduler's failure modes too.

The word "dynamic" deserves attention. A static workflow is a pipeline you draw in advance: agent A, then agent B, then agent C. A dynamic one, at least as the name implies, decides some of its structure at runtime. That is more powerful and less predictable at the same time. Keep that trade-off in your head through the rest of this piece, because it's the Capability vs. Controllability Frontier in miniature: the more the system decides for itself, the harder it becomes to reason about in advance.

To see why a native orchestration layer matters, it helps to name the problem it replaces. This section is analysis drawn from how multi-agent setups commonly behave, not from Anthropic's materials.

Most people's first multi-agent system is a relay race. A research agent gathers material, hands a summary to a drafting agent, which hands a draft to a review agent. It works in a demo. Then it meets a real workload and three things go wrong.

• Everything waits on the slowest step. If research takes twenty minutes, nothing else happens for twenty minutes, even when parts of the job don't depend on research at all.
• Context degrades at every handoff. Each agent only sees what the previous one chose to pass along. Details get dropped, and nobody notices until the end.
• Failures are silent or total. If the middle agent stalls, the relay stops, and often you only find out because the final output never arrives.

The cost of that wall compounds. You add retries by hand. You add a checker agent to check the checker. You start keeping a spreadsheet of which runs finished. At that point you are running an orchestration system anyway: a bad, improvised one held together by your own attention.

The Scout's thesis for this piece, which we share, is that flows are aimed squarely at that wall: the shift from sequential handoffs toward a coordinator that can run independent work side by side and pull results back together. To be precise about evidence, the workshop summary confirms the orchestration framing and the "most ambitious workloads" target. It does not, in the excerpt available to us, spell out parallel execution mechanics. The inference is strong: it's hard to describe a multi-agent orchestrator built for ambitious workloads that only ever runs one agent at a time. But you should verify the specifics against Anthropic's documentation before you redesign anything around them.

If the inference holds, the practical change for you is this: the shape of the work, not your patience, becomes the limit on how many agents you can usefully run at once.

Here is the gotcha that catches almost everyone who scales from one agent to many. You expect the hard part to be making agents smarter. The hard part is actually knowing when the overall job is done, and whether it's done correctly.

You don't have to take our word for how subtle this gets. On the same day as the workshop, LangChain shipped a LangGraph SDK release whose changelog includes a fix to "end a thread stream's run only on a root lifecycle event." Translated out of engineering language: in a system where work spawns other work, the platform had to be taught not to declare the whole job finished just because one inner piece finished. That's a bug class, not a one-off, and it's exactly the kind you'll meet in any orchestrated system, Anthropic's included.

So before you hand a big workload to a flow, walk through these questions. You'll want answers written down, not assumed.

• What does "done" mean? Define the finished state of the whole job, not each agent's piece. If you can't say it in one sentence, the orchestrator can't check for it either.
• What happens when one branch fails? Does the whole flow stop, continue without that branch, or retry? Each answer is defensible. Not knowing which one you're getting is not.
• Who reconciles conflicting outputs? When two agents working side by side reach different conclusions, something has to choose. Make sure it's a rule you set, not a coin flip you discover later.
• What's the spending ceiling? More agents running at once means cost arrives faster. Set a hard cap per run before your first ambitious workload, not after your first surprising invoice.

This is where The Autonomy Spectrum earns its place. Agent deployments run from copilot to full autonomy, and most failures come from deploying at the wrong point. A dynamic workflow pushes you further toward the autonomous end by default, because a coordinator is now making decisions you used to make between steps. That's fine, as long as it's a decision you made deliberately.

If orchestration moves the failure points, observability is how you find them. The quiet story around this launch is that the tooling for watching agents is maturing on the same schedule as the tooling for running them.

In the twenty-four hours around the workshop, several observability projects shipped updates. Langfuse, a widely used tracing and evaluation platform for LLM apps, put out its v4.58.0 release, including work on how it handles media in OpenTelemetry traces. Arize's Phoenix project, another tracing toolkit, shipped a component update keeping pace with newer Python versions. Neither release is about Anthropic. Both are reminders that the ecosystem treats "what did my agents actually do?" as an ongoing engineering problem, not a solved one.

There's a smaller, homelier example worth your attention too. Simon Willison updated his datasette-ports plugin, which lists every running instance of his Datasette tool on a machine and now shows each one's process ID so he can attach a profiler. Strip away the specifics and the lesson generalizes: once you have many things running at once, the first tool you need is one that tells you what's running.

Apply that to flows. Before your first serious run, make sure you can answer three questions without guessing.

• Which agents are running right now? You want a live list, not a reconstruction from logs after the fact.
• What did each agent receive and return? Every handoff is a place where context can be lost. You can't fix lost context you can't see.
• Where did time and money go? In an orchestrated job, one runaway branch can dominate the cost of the whole run.

If Anthropic's built-in views cover all three, good. If they don't, plan to pair flows with an external tracing tool before scaling up. Debugging a dozen agents by reading final outputs is like debugging a program by staring at its last line of output.

Every time data passes from one agent to another, it crosses a boundary. In a single-agent setup you have a handful of those crossings. In an orchestrated system you may have dozens per run, created at runtime, some of which you never explicitly designed. That's the Trust Boundary Model in practice: each crossing is a place where you need to inspect and enforce, and orchestration multiplies them.

The most practical illustration in this week's material came from outside the Anthropic ecosystem entirely. Willison described being mid-project on his phone and wanting to edit a credentials file "without round-tripping those credentials through the LLM itself." His fix was to have an agent build a small web app for viewing and editing files, run over his private Tailscale network, so the secrets never pass through the model.

That instinct is exactly the one you'll want when you start designing flows. Secrets that one agent needs should not become context that every downstream agent inherits. A coordinator that shuttles context between agents is, by design, very good at spreading information around. That's the feature. It's also the risk.

• Scope credentials to the agent that needs them. If only the deployment step needs a key, no research or drafting agent should ever see it.
• Assume handoffs are logged. Whatever crosses between agents may end up in traces and observability tools. Design as if it will.
• Watch for shadow flows. Once orchestration is easy, people on your team will build their own. That's The Shadow Agent Problem: tools adopted without review carry broader access than the old Shadow IT ever did. A flow built by one enthusiastic colleague can touch more systems in an afternoon than a single rogue agent could in a week.

None of this is a reason to avoid flows. It's a reason to decide your boundaries before the coordinator decides them for you.

Flows reset what a team of agents can be asked to do. That's the capability inflection. The practical question is how you adopt it without inheriting a scheduler's worth of new bugs on day one. Here's the order we'd suggest.

1. Read the primary material yourself. Start with the workshop coverage and then Anthropic's own documentation. Separate what's confirmed from what commentators, including us, are inferring.
2. Pick one workload that already hurts. Choose a job you currently run as a hand-wired relay, where you know the slow steps and the common failures. You want a baseline to compare against.
3. Write down "done" and "failed" before you build. One sentence each. If you can't, the job isn't ready to orchestrate.
4. Set a cost cap and a time cap per run. Do this first. You'll be tempted to skip it for a test. Don't.
5. Wire up visibility. Confirm you can see every running agent and every handoff, using Anthropic's views or an external tracer.
6. Audit what crosses each boundary. Remove credentials and sensitive data from any handoff that doesn't strictly need them.
7. Run it supervised before you run it unattended. Sit closer to the copilot end of the Autonomy Spectrum for the first several runs, then move toward autonomy only as the failure patterns become boring.

The bigger picture is worth one more sentence. By building orchestration into Claude Managed Agents rather than leaving it to third-party frameworks, Anthropic is pulling the coordination layer, the part of the stack that decides how agents work together, inside its own harness. If The Harness Hypothesis is right, that's where the durable value sits. Your job is simply to make sure the value lands in your work and not in your incident log.