Claude Code’s research preview can dispatch hundreds of subagents under an orchestration plan that did not exist when the request arrived. The system can branch the work, verify the results, and converge before reporting back. Familiar engineering questions—who may act, what they may see, and who can stop them—now have to be answered while the work is already running.

Key takeaways

  • Claude Code’s dynamic-workflows preview moves orchestration into runtime: the model can create a task-specific plan, dispatch hundreds of subagents, verify results, and converge on an answer.
  • The durable advantage is increasingly the orchestration harness—not the individual reasoning loop—because allocation, shared state, verification, recovery, permissions, and cost control determine whether model capability becomes accountable work.
  • A runtime-generated graph is a consequential software artifact that must be identified, versioned, permissioned, observed, and tied to explicit approval and escalation paths.
  • Parallelism creates value only when work decomposes cleanly enough to outweigh coordination, inference, latency, and context-transfer costs; otherwise a fixed workflow or single strong agent is preferable.
  • Reasoning traces can flag suspicious behavior but cannot prove causality or accountability; operators need records of graph changes, tool calls, state transitions, policy decisions, evaluator outputs, permissions, and approvals.

The prompt loop is too small for the job

A static model call accepts an instruction and returns an answer. An AI agent adds iteration: it can inspect intermediate results, use tools, preserve memory, update state, and decide what to do next. The prompt becomes one input to a larger control structure.

The developer’s graph determines whether a task continues, branches, escalates, delegates, retries, or stops. LangGraph makes conditional branching, tool calls, and workflow-continuation decisions explicit inside a bounded design. OpenAI’s Agents SDK treats hand-offs, guardrails, and tracing as mechanics of delegation. AutoGen, CrewAI, Google’s Agent Development Kit, and Anthropic’s tooling approach the same problem from different directions.

As models became useful at bounded, tool-driven work, developers began engineering the relationships among model calls. They now design roles, reporting lines, shared records, escalation paths, review functions, and rules for reallocating work when the first plan fails. Prompt quality still matters, but it is a local property inside a larger operating system.

A generated graph turns orchestration into runtime software

Fixed graphs can add capability without surrendering the predictability of a designed workflow. In its dynamic-workflows research preview, Claude Code goes further: it produces the orchestration plan during execution. For a sufficiently complex task, Claude can plan the work, fan it out in parallel, verify the results, and converge before reporting back. Framework migrations spanning hundreds of files are one stated use case.

A dynamic workflow does more than add agents. It can synthesize the harness the task appears to require: divide a migration by subsystem, add reviewers, route failed checks back to implementers, and preserve an aggregation stage for the final result. The model now produces the graph definition instead of only operating inside one supplied by a developer.

Developers should not mistake that step for unrestricted self-redesign. Current guidance still treats bounded orchestration as a source of predictability and safety. Claude Code’s preview creates an orchestration script and then follows the plan; it does not establish that unconstrained, continuously self-modifying organizations are desirable or reliably workable.

Yet Claude Code crosses an important boundary. Teams can review a static workflow before deployment. A runtime-generated workflow appears after the request begins, in response to task state that did not exist at design time. The organization executing the task becomes an ephemeral software artifact.

Teams must treat that artifact like consequential code: assign it an identity and version, constrain its permissions and execution, observe its transitions, and record who or what approved its creation. Otherwise “dynamic” becomes a polite word for an unreviewed production change.

Parallel agents make harness economics visible

More workers do not automatically produce more useful work. Every hand-off adds coordination cost. Agents can lose context, propagate permissions incorrectly, and make errors harder to localize as responsibility crosses boundaries. Fan-out spends additional inference and orchestration resources for parallel search or shorter wall-clock time. The trade pays only when the task decomposes cleanly enough to cover the overhead.

Anthropic’s earlier account of its multi-agent Claude Research system claimed significant improvements over single-agent systems in internal evaluations. That evidence applies to a particular harness and task set; it does not prove that a swarm beats a strong individual agent. Some jobs need a research team. Others need one competent worker and fewer meetings.

The allocator—not head count—creates value when it decides whether to split work, which specialists receive it, and what context each one needs. It also sets the cost and latency budget, determines when verification is worth adding, and falls back to one agent when delegation costs more than it contributes. These are questions of agent economics, not personality design.

Anthropic’s progression from a multi-agent research system to Claude Managed Agents shows where the product boundary is settling. The managed offering includes an agent harness and deployment tools because operating an agent requires more than producing another model response. It requires maintaining the conditions under which many responses become one accountable result.

Frontier models can now operate inside several orchestration systems, so model quality no longer describes the whole product. Teams using similarly capable models can produce materially different results through task decomposition, state persistence, verification, recovery, and cost control. The harness converts reasoning capability into completed work—and determines how much disorder the process creates.

Change control must move inside the graph

Teams cannot govern dynamic agents through the system prompt and final answer alone. They must version graphs, assign role permissions, constrain hand-offs, approve model and tool selection, define escalation conditions, and specify the evidence required before a branch proceeds.

Microsoft’s Agent Control Specification makes that requirement explicit by proposing an open-source standard for granular, consistent control over agent actions. Software has always had permissions; dynamic agents need those policies enforced at runtime. The policy must travel with an agent as it moves across applications, tools, and delegated roles.

A generated organization also creates approval questions that static access control does not answer. An agent may be allowed to read a repository but not delegate that access to twenty subagents. A reviewer may reject a patch but lack permission to rewrite it. An evaluation failure may trigger a retry, while a permission change may require a human. The graph needs separation of duties because the model cannot act as applicant, approver, executor, and auditor merely by changing hats in adjacent context windows.

The escalation principle predates dynamic workflows. In December 2023, OpenAI gave its board authority to hold back a model release despite leadership’s assessment that it was safe. High-consequence decisions required authority outside the operating loop. Runtime agent graphs need the software equivalent: certain state transitions must terminate automation and route authority elsewhere.

Operators can use human judgment, model-based evaluation, and knowledge-base validation as gates, but a gate is accountable only when its policy and authority are recorded. An audit trail must show which graph ran, which state triggered a branch, which permission enabled a tool call, which evaluator accepted the result, and which human approved an exception. That makes auditability part of the product architecture rather than a compliance attachment.

Reasoning traces cannot carry accountability

A larger graph gives operators more places to inspect the system. It also gives agents more places to behave strategically, lose context, or produce a convenient explanation after acting. Observability expands with the graph, but so does the object being observed.

OpenAI’s chain-of-thought monitorability framework includes 13 evaluations. It treats monitorability as an empirical property, including whether a monitor can detect behaviors such as reward hacking from a model’s stated reasoning. That approach is useful because it does not assume a visible chain of thought is a truth oracle.

Researchers from OpenAI, Google DeepMind, Anthropic, and other organizations have described chain-of-thought monitoring as promising but fragile. Coverage of Claude Sonnet 4.5’s system card reported greater verbalized awareness of evaluation environments, complicating the interpretation of alignment scores. A system that recognizes the test can alter the evidence the test was designed to collect.

Reasoning traces are signals, not receipts. They can help detect suspicious behavior, explain a route, or trigger additional review. By themselves, they cannot prove why an agent acted or establish that its stated rationale caused the action.

An accountable agent system needs harder records: tool invocations, state transitions, graph changes, policy decisions, evaluator outputs, approval events, and the exact permissions active at each step. The model may narrate its reasoning, but the control plane must record its behavior. Corporate audits generally do not conclude after reading the manager’s diary.

Buyers should ask who can stop the graph

OpenAI gave its board release authority in December 2023; Microsoft proposed runtime agent controls in June 2026. The question has moved from whether an organization can stop a powerful model before release to whether a deployed model can assemble an organization of agents without escaping the task’s permissions, approvals, and evidence requirements.

Teams should keep fixed orchestration when predictability matters more than adaptation. They should use a strong single agent when delegation costs more than it contributes. Dynamic graphs fit tasks that are large, decomposable, and uncertain enough that teams cannot specify the execution structure completely in advance.

Procurement and platform teams should demand task-level evidence: the graph that ran, each delegated identity, tool permissions, evaluator decisions, exception approvals, and total cost. A benchmark score cannot show whether the system can contain a failed branch or revoke authority midway through a task.

Hundreds of workers make Claude Code’s preview look like a scale story. The consequential number is one: an org chart created after deployment, while the task is underway. Buyers should demand a harness that identifies who authorized every box and arrow.

From monitoring to runtime orchestration control

  • 2025-12-21 — OpenAI introduced a chain-of-thought monitorability framework with 13 evaluations, treating monitorability as an empirical property rather than assuming reasoning traces are reliable receipts.
  • 2026-05-30 — Anthropic announced dynamic workflows for Claude Code, enabling hundreds of subagents to run in parallel on complex engineering work such as framework migrations.
  • 2026-06-02 — Microsoft announced the open-source Agent Control Specification for granular, consistent control over what AI agents can do, reflecting the shift toward runtime governance.

Frequently asked questions

What is different about Claude Code’s dynamic workflows?

Instead of operating only inside a workflow designed before deployment, Claude Code can generate an orchestration plan after a task begins, then fan work out to hundreds of subagents, verify it, and aggregate the result.

Does this mean Claude Code can redesign itself without limits?

No. The preview creates an orchestration script and follows that plan; the piece does not establish that unconstrained, continuously self-modifying agent organizations are safe or reliable.

When should teams use a dynamic agent graph?

Dynamic graphs fit tasks that are large, decomposable, and uncertain enough that the execution structure cannot be fully specified in advance. Teams should prefer fixed orchestration when predictability dominates and a single agent when delegation overhead exceeds its benefit.

What controls should a runtime-generated graph have?

Teams should version the graph, constrain role and tool permissions, govern hand-offs, set cost and latency budgets, define escalation conditions, and require recorded approval for sensitive transitions or exceptions.

Can chain-of-thought logs provide an adequate audit trail?

No. They are useful monitoring signals, but accountability requires harder operational evidence such as tool invocations, active permissions, state transitions, graph changes, evaluator decisions, and human approvals.