Dynamic Workflows Bring Parallel Agent Coordination to Claude Code

The problem: single‑agent limits on complex engineering work

Modern software projects routinely involve tasks that exceed the capacity of a single LLM prompt. Consider a security audit that must scan thousands of repositories, a multi‑service migration that touches dozens of APIs, or a bug‑hunt that spans multiple micro‑services and runtime environments. In a traditional Claude Code session the engineer must manually decompose the problem, invoke the model repeatedly, stitch together partial results, and keep track of state across dozens of API calls. The process is error‑prone, difficult to parallelise, and often stalls when the model runs out of context length or token budget.

These limitations manifest in three concrete pain points:

1. Scalability – A single agent cannot run many independent sub‑tasks concurrently; each sub‑task must be queued sequentially, leading to hours‑long runtimes.
2. Consistency – When multiple sub‑tasks produce overlapping or contradictory findings, the engineer must manually reconcile them, risking missed edge cases.
3. Reliability – Interruptions (network glitches, token limits, or user cancellations) force a full restart because the workflow state is not persisted.

The solution: Dynamic Workflows as on‑demand orchestration scripts

Anthropic’s Dynamic Workflows (available in research preview for Claude Code Max, Team, and eligible Enterprise plans) addresses these issues by turning a high‑level user intent into an executable orchestration graph. The workflow engine performs four steps automatically:

1. Planning – Claude parses the user’s goal, identifies logical sub‑tasks, and selects specialized sub‑agents (e.g., a code‑analysis agent, a security‑scanner agent, a performance‑profiling agent).
2. Parallel execution – Sub‑tasks that are independent are dispatched concurrently, leveraging Claude’s internal thread pool. Token usage scales roughly linearly with the number of agents, but wall‑clock time drops dramatically.
3. Verification – Results from each sub‑agent are compared against each other and against predefined invariants (e.g., “no new lint errors”, “all migration scripts compile”). Discrepancies trigger a re‑run of the offending sub‑task.
4. Convergence & reporting – Once all checks pass, the engine aggregates the findings into a single, human‑readable answer and persists the intermediate state so that a later resume continues from the last successful checkpoint.

Developers can trigger a workflow explicitly (Claude, create a workflow to audit our monorepo) or enable the ultracode flag, which lets Claude decide when a workflow is beneficial. The feature is exposed through the Claude API, as well as via partner platforms such as Amazon Bedrock, Google Vertex AI, and Microsoft Foundry.

How it works under the hood

• Task graph generation – Claude builds a directed acyclic graph (DAG) where nodes represent sub‑agents and edges encode data dependencies. The graph is serialized to a JSON‑compatible format that the runtime can replay.
• State store – A lightweight key‑value store (backed by DynamoDB on Bedrock or Cloud Firestore on Vertex) holds each node’s input, output, and verification status. This enables exact‑once execution semantics even across restarts.
• Token budgeting – Before dispatch, the engine estimates token consumption per node and caps the total budget. If the estimate exceeds the user‑defined limit, Claude suggests a narrower scope.
• Result merging – A deterministic merge function (configurable per workflow) resolves conflicts, for example by preferring the most recent security scan or the highest‑confidence lint report.

Trade‑offs and practical considerations

Aspect	Benefit	Cost / Limitation
Scalability	Parallel execution reduces end‑to‑end latency from hours to minutes for embarrassingly parallel tasks.	Token consumption can increase 2‑5× because each sub‑agent repeats prompt context.
Consistency	Automated verification catches contradictory outputs before they reach the user.	Verification logic must be authored for each domain; generic checks (e.g., JSON schema) may miss domain‑specific nuances.
Reliability	Persistent state allows resumable runs; crashes no longer force a full restart.	State store adds external dependency and latency; mis‑configured permissions can cause silent failures.
Developer experience	No need to hand‑craft orchestration scripts; Claude generates them on demand.	Loss of fine‑grained control; developers may find the auto‑generated DAG opaque and harder to debug.
Cost	Enables one‑click large‑scale audits that previously required dedicated engineering effort.	Higher token spend translates directly to higher API costs; budgeting is essential for production use.

When to use Dynamic Workflows

• Large‑scale static analysis – Running linters, type checkers, or security scanners across dozens of repositories.
• Multi‑service migrations – Coordinating schema changes, config updates, and compatibility tests in parallel.
• Root‑cause investigations – Splitting a widespread outage into per‑service logs, reproducing each locally, and reconciling findings.

When to stick with a single agent

• Small, interactive debugging – Where the overhead of graph generation outweighs the benefit.
• Highly stateful, sequential tasks – E.g., a step‑by‑step refactor that depends on the exact output of the previous step.
• Token‑budget constrained environments – If the cost of parallelism exceeds the value of speed.

Looking ahead

Dynamic Workflows signal a shift from model‑centric AI to orchestration‑centric AI. As more vendors expose specialized agents (code‑gen, test‑generation, security‑review), the ability to compose them dynamically will become a core competency for engineering teams. The research preview will likely evolve to include:

• Custom agent registration – Allowing organizations to plug in internal tooling (e.g., proprietary static analysis) as first‑class sub‑agents.
• Adaptive budgeting – Real‑time token‑cost feedback that prunes low‑value branches of the DAG.
• Observability dashboards – Visual DAG renderings that show progress, failures, and token spend per node.

For early adopters, the pragmatic approach is to start with narrowly scoped workflows—say, a single‑repo security scan—and gradually expand as you become comfortable with the token economics and verification patterns.

---

Robert Krzaczyński is a senior software engineer who writes about AI‑augmented development. Follow his work on GitHub and the Anthropic API docs.