How Anthropic’s Dynamic Workflows Coordinate Claude Agents

What it claims

Anthropic presenters (CJ Avilla and Harrison Stall) described flows as a feature announced the Friday before the workshop. In a flow, the lead Claude agent picks its own multi-agent topology. The idea grew out of the "a harness for every task" concept in Claude Code. Flows are meant to run longer than a single agent or a fixed roster, and are pitched as "a way to throw test-time compute at hard problems." In a watchlist-scanner comparison, Avilla said flows cost "much more" than a single agent but were "much more effective at finding all of the details." No figures were given for either cost or effectiveness.

How it works

1. The lead agent writes a plan.
2. Claude writes an orchestration program from that plan. The program launches agents, collects their results and routes information between phases.
3. You can still pass pre-configured specialist subagents in the agent config. Claude does not have to invent every role.

The demo was a stock watchlist scanner. A scan phase gave each ticker to its own agent, each with an isolated context. A review phase then examined the combined findings and produced a report.

flowchart LR
  L[Lead agent writes orchestration program] --> A1[Ticker agent]
  L --> A2[Ticker agent]
  L --> A3[Ticker agent]
  A1 --> FS[(Shared filesystem)]
  A2 --> FS
  A3 --> FS
  A1 --> R[Review phase]
  A2 --> R
  A3 --> R
  R --> Rep[Report]

How to use it

These points come from the Q&A and decide how you would configure a flow:

• Parallelism. The number of agents is governed by "evals and lower defaults." Ambitious tasks generally need you to explicitly ask for more parallelization. Don't expect wide fan-out by default.
• Budget. The model does not know its budget while it runs. Set a session budget yourself. Anthropic chose not to tell the model its budget, saying it could make agents "a little bit anxious."
• Inter-agent communication. Subagents share a filesystem and can exchange data through it. The API offers no way to tell one subagent to message another.
• Observability. The Claude Console graph view shows the payload the lead agent passed to each subagent, for every transition.
• Reducing repeat cost. You can ask Claude to review the costs it incurred, or use dreaming. Dreaming reads an existing memory store plus past session transcripts and writes a reorganized store: duplicates merged, stale or contradicted entries replaced, new insights surfaced.

Limits

• No self-improvement. A flow cannot revise itself between runs, for example by swapping out an inadequate scanning approach before the next scheduled run. The presenters suggested hill-climbing and dreaming as manual workarounds.
• Dreaming is a research preview.
• Cost. Flows cost substantially more than a single agent. The only comparison given was qualitative.
• Unproven at scale. The only demonstrated workload was the simple watchlist scan. Stall declined to give specifics on large scientific workloads.
• Source type. This is a conference report, not documentation. It gives no API shapes, config syntax or pricing.