On October 9, Anthropic added a test capability to its managed agents called dynamic workflows. In plain terms, you can now let a single agent write a program that breaks a job like reviewing hundreds of documents into phases, dispatches a swarm of sub-agents to run them in parallel, and merges the results. The server runs that workflow in the background, so you are not stuck watching it the whole time.
This attacks the oldest headache in multi-agent work: orchestration. Until now, getting a group of agents to cooperate meant either hard-coding the flow by hand or shuttling things back and forth yourself. Now an agent can decide on its own when to start a workflow, how to phase it, and what order things should run. You turn it on by setting the multi-agent field to on and telling it in the system prompt when to begin, then you follow each run through the event stream.
In the same week Anthropic published two companion pieces that make the intent clearer. One walks through building effective agent automations, shipping a reference implementation with config files and six rules for avoiding common failure modes. The core lesson is simple: do not let automation drift out of view where no one is watching. The other covers automating eval design and hill-climbing with the model, and its theme is do not fool yourself. When the eval score goes up, you have to tell whether the model actually improved or just found a loophole.
For anyone building agent systems this is a concrete signal. Multi-agent is moving from sounds-great to shippable, and the deciding factor is not how strong any single model is. It is whether the orchestration layer is reliable and whether the failure modes are controllable. Anthropic is clearly productizing this layer. Google's coworker agent, announced the same week, points the same way. Both bets assume the future is not a person chatting with one box, but a person managing a swarm of agents, each with its own identity.
But the trap is obvious. Once a workflow can generate itself, debugging gets exponentially harder. You now have to understand not just the agent's output but the program it wrote. Permissions, cost, and rollback, already hard in the single-agent era, get harder by an order of magnitude. More practically, when dozens of sub-agents run in parallel, one stall can drag down the whole pipeline, and pinpointing which step broke is a magnitude more annoying than single-threaded debugging.
Take a workflow that actually lands. A legal team needs to pre-review five hundred vendor contracts for key clauses and conflicts. The old way is one person plus search, or a one-off script. Now a lead agent can generate a workflow that buckets contracts by risk type, dispatches sub-agents to extract in parallel, and merges everything into one table. High volume, clear rules, parallelizable: exactly the sweet spot for dynamic workflows.
Do not mythologize the capability either. Dynamic workflows do not let you walk away. They move the complexity of orchestration from human hands into the agent itself. The upside is speed. The downside is that when the generated program has a logic hole, you cannot see at a glance where it broke. So for the first wave, keep workflows inside tasks where a mistake is easy to spot, and keep a human review node. At the end of the day, multi-agent solves a problem of scale, not a problem of trust. As volume goes up, the boundary of trust has to tighten, not loosen.
To its credit, the company did not skimp on observability. Every workflow run emits progress through an event stream, so you can see which phase is running, how many sub-agents were dispatched, and where things stalled. That sounds basic, yet it is the difference between multi-agent work landing in production or not. Without that visibility, running dozens of agents in parallel is like managing a factory blindfolded. So if you adopt this, wire the event stream into your existing monitoring in the first wave. Do not wait for an incident to scramble through logs. You only dare to let go once you can see.
One more practical note for builders. The trigger prompt is now the highest-leverage asset you own. A vague objective spawns vague sub-tasks and merges into mush, while a crisp one lets the swarm actually deliver. The skill that pays has shifted from writing code to writing instructions a machine can grip reliably.
What this means for you: if you already use or plan to use this model for automation, try dynamic workflows immediately. They fit high-volume, well-specified, parallelizable work especially well, things like batch contract pre-review or large-scale code migration. But in the first wave, set hard spend caps and human checkpoints. Do not let a swarm free-run in the background and discover only later that both the bill and the errors have piled up into a mountain.