Claude Flows: Hand It a Goal, It Runs 1,000 Agents

On October 9, Anthropic moved dynamic workflows into public beta for Claude Managed Agents. The mechanism is straightforward but the implications are not: a lead agent writes a JavaScript program that spawns up to 1,000 agents across phased execution, with 64 running concurrently, and Anthropic's servers run it in the background. You enable it with one configuration flag — multiagent_20261001 — and Claude decides when and how to use it. At the AI Engineer conference in New York, Anthropic staff called them "flows." The community ran with it.

📖 Read the full version with charts and embedded sources on AgentConn →

We covered the orchestration landscape last week when this dropped. That article asked: where is the frontier shifting? This one asks a different question: what is the actual mechanism, and does it hold up under scrutiny?

The answer is more nuanced than the headline suggests.

Why Single Agents Break Down

Before diving into the mechanism, it helps to understand what problem dynamic workflows solve. Anthropic's own blog post names three failure modes that emerge when you push a single long context window:

1. Agentic laziness. Claude "declares the job done after partial progress" — addressing 35 of 50 items in a security review and calling it complete.
2. Self-preferential bias. A tendency "to prefer its own results or findings, especially when asked to verify or judge them against a rubric."
3. Goal drift. "The gradual loss of fidelity to the original objective across many turns, especially after compaction."

These are not theoretical. Anyone who has run a 50-turn Claude Code session on a complex codebase has seen all three. The first one — agentic laziness — is particularly insidious because the agent confidently reports completion. You only discover the gap during review.

Dynamic workflows address these by splitting work across agents with isolated context windows. Each agent gets a bounded piece of the objective and has no temptation to declare victory on the whole task. A separate synthesis agent compares results without the sunk-cost bias of having produced them.

💡 The core insight: The problem is not that Claude is too dumb to handle large tasks. It is that a single context window creates structural incentives for partial completion, self-confirmation, and objective drift. Separate contexts eliminate the structural problem.

The Three Primitives

At its core, a dynamic workflow is a JavaScript file. Claude writes one per task, tailored to the specific work. The runtime provides three primitives:

agent(prompt, opts)

Spawns one subagent. prompt is the only required input. Options include:

• schema — returns validated JSON instead of free text
• model — choose opus, sonnet, or haiku per agent
• isolation — worktree or remote, so agents can work on code in parallel without conflicts
• agentType — selects a predefined agent from your roster

parallel()

Fans out multiple agents simultaneously and waits for all results. This is the barrier pattern — execution continues only when every parallel agent reports.

pipeline()

Streams each item through every stage sequentially. Think of it as array.map() but each stage is an agent call.

That is the entire API surface. Three functions. Everything else — phasing, error handling, data passing — is standard JavaScript. JSON, Math, Array are all available. The harness is disposable: Claude writes a new one for every task and discards it afterward.

// Simplified example: parallel security audit
const files = await agent("List all API route files", {
  schema: { files: ["string"] }
});

const findings = await parallel(
  files.map(f => agent(`Audit ${f} for SQL injection and XSS`, {
    model: "opus",
    schema: {
      file: "string",
      vulnerabilities: [{
        type: "string",
        severity: "string",
        line: "number"
      }]
    }
  }))
);

const report = await agent(
  `Synthesize findings and rank by severity:\n${JSON.stringify(findings)}`,
  { model: "opus" }
);

Six Workflow Patterns

Anthropic documents six patterns that emerge from these primitives. Each solves a different coordination problem:

The adversarial verification pattern is the most interesting for production use. Instead of one agent reviewing its own work (self-preferential bias), a second wave of agents independently tries to find problems in the first wave's output. This is what drove the headline benchmark.

The Latent Space deep dive from CJ Avilla and Harrison Stall's AI Engineer NYC talk is the best technical breakdown of how these patterns compose in practice.

The Benchmark: 66 Out of 70 Bugs

Anthropic's internal test planted 70 bugs in a 116,000-line codebase. Results across three runs each:

• Single agent: found 14, 15, and 27 bugs (20-39% recall, high variance)
• Dynamic workflow: found 66 bugs each time (94.3% recall, near-zero variance)

The consistency matters as much as the recall. A single agent's performance varied by nearly 2x across runs — you cannot predict whether you will get the 14-bug run or the 27-bug run. The workflow found 66 every time.

But context matters. This is Anthropic testing its own feature on its own benchmark. The codebase is synthetic, the bugs are planted, and no cost or runtime figures are published. Independent replication does not yet exist.

⚠️ Contrarian corner: The 94.3% recall is impressive, but the absent figures are telling. How many tokens did each workflow run consume? At what dollar cost? If a workflow runs 50+ Opus agents and each burns through its full context, you could easily exceed $50-100 per run. The 66/70 number is meaningless without the cost denominator. And the four bugs it still missed? Those are the ones that matter most in production — the ones that survive everything you throw at them.

Two Runtimes, Two Scale Points

Dynamic workflows exist in two places, and they are not identical:

Claude Code (Developer Tool)

• Launched: May 28, 2026 (research preview, now generally available)
• Concurrency: Up to 16 subagents simultaneously
• Total per run: Up to 1,000
• Triggers: Use the word "workflow" in a prompt, use ultracode mode, or ask for a "quick workflow"
• Runtime: Local JavaScript execution
• Model: Opus 4.8 writes the harness

Claude Managed Agents (API)

• Launched: October 9, 2026 (public beta)
• Concurrency: Up to 64 agents simultaneously
• Total per run: Up to 1,000
• Configuration: multiagent_20261001 type, managed-agents-2026-04-01 beta header
• Runtime: Anthropic's servers, background execution
• Cost: Standard model token rates + $0.08/session-hour

The API version is the one that matters for production systems. Here is the minimum configuration:

{
  "multiagent": {
    "type": "multiagent_20261001",
    "workflows": {
      "type": "enabled",
      "inline_agents": { "type": "enabled" }
    }
  }
}

You do not make a separate API call to start a workflow. The agent decides whether to start one based on your message or system prompt. Workflow progress streams as workflow_run.* events on the session event stream.

Key constraints from the official docs:

• Delegation is one level deep — subagents cannot create their own subagents
• A workflow can list up to 20 predefined agents
• Runs last up to 24 hours by default
• A session can have 10 runs open simultaneously
• The agent cannot send follow-up messages to a run's threads after the run ends

What the Community Actually Thinks

The Hacker News thread (200 points, 135 comments) is more instructive than the launch post. The signal splits into three camps.

The Skeptics: Cost and Control

SkyPuncher — the top comment — argues that "correctness, not speed, is the bottleneck" and wants better ways to steer long sessions and inject corrections. This hits a real limitation: once a workflow starts, you cannot course-correct mid-run. The program is committed.

Syntaf reports the sharpest cost data point: spawning 62 Opus sub-agents exhausted a Max plan's five-hour usage limit in approximately 18 minutes. ncphillips hit their Max plan limit for the first time after roughly 90 agents ran a code review of a small package.

The Pragmatists: It Works When Bounded

afro88 reports "good parallelization and phasing, with cleaner context windows yielding better results on large tasks." They like the terminal UI's visibility but note the inability to steer agents mid-run.

bcherny from the Claude Code team shared internal metrics: workflows reduced token usage about 15% on repeated tasks and cut Agent SDK startup time by 61%. These are more credible than the bug-finding benchmark because they measure operational improvements, not synthetic performance.

The Architectural Critics

vadansky describes "slop debt" — where repeated agent passes compound messy code. In their example, the model kept adding casts and complexity instead of suggesting a type split that a human eventually saw.

tomjakubowski calls the Bun Rust PRs produced by workflows "some of the worst code they've seen," citing tests that merely repeat the implementation. This is the quality concern that no benchmark addresses.

💡 What This Means for You: Start with bounded, high-value tasks — security audits, dependency upgrades, migration validation. Use adversarial verification (the pattern that drives the benchmark numbers). Set a session budget before your first run. And do not trust the output without human review, especially for generated tests.

How It Compares to the Alternatives

Dynamic workflows are not the only multi-agent orchestration approach. Here is how they stack up against the leading orchestration tools:

The disposable harness is the key differentiator. LangGraph, CrewAI, and Swarm all require you to define the orchestration structure upfront. Claude writes a new one per task.

The trade-off is control. Every competitor lets you intervene mid-run. Dynamic workflows do not. If the plan is wrong, you discover it when the run completes. For fleet orchestration at scale, this is a real limitation.

The Real Cost Equation

Nobody is publishing detailed cost analyses yet, but we can triangulate from the data points:

• Syntaf's report: 62 Opus agents consumed 5 hours of Max plan usage in 18 minutes
• ncphillips: ~90 agents on a small code review hit the plan limit
• Anthropic's sample runs: review-changes used 14 agents and 482K tokens in ~6 minutes; deep-research used 22 agents and 1.1M tokens in ~11 minutes
• Managed Agents pricing: Standard token rates + $0.08/session-hour

If each Opus agent uses ~50K tokens (a modest estimate for a bounded review task), a 20-agent workflow burns 1M tokens. At Opus rates, that is roughly $15 per run for input and $75 for output. A 100-agent workflow could easily reach $300-500.

The economics only work when the task justifies it. A security audit that finds critical vulnerabilities before production? Worth $300. A code review of a pull request? Use a single agent.

The API in Practice

For teams ready to integrate, here is what the Managed Agents setup looks like:

# 1. Create predefined agents
security_agent = client.beta.agents.create(
    name="security-reviewer",
    model="claude-opus-5-5",
    system="Analyze code for SQL injection, XSS, CSRF, and auth bypass.",
    tools=[{"type": "agent_toolset_20260401"}],
)

# 2. Create lead agent with workflow support
lead_agent = client.beta.agents.create(
    name="audit-lead",
    model="claude-opus-5-5",
    system="Coordinate security audits. Use a dynamic workflow for repos with 10+ files.",
    tools=[{"type": "agent_toolset_20260401"}],
    multiagent={
        "type": "multiagent_20261001",
        "workflows": {
            "type": "enabled",
            "predefined_agents": [
                {"type": "agent", "id": security_agent.id}
            ],
        },
    },
)

# 3. Create session and send work
session = client.beta.sessions.create(
    agent=lead_agent.id,
    environment_id=environment.id,
)

response = client.beta.sessions.send_message(
    session_id=session.id,
    message="Audit this repository for security vulnerabilities.",
)

💡 Budget controls: Always set a session budget via the Managed Agents API. When a session hits its budget, all open runs pause — but each working agent finishes its current request, so actual spend can slightly exceed the cap. Monitor workflow_run.* events to track progress and cost accumulation in real time.

Where This Is Going

Dynamic workflows are in public beta, which means the API surface may change. But the direction is clear: Anthropic is betting that the orchestration layer should be generated, not configured.

This inverts the assumption behind every existing framework. LangGraph says: define your graph. CrewAI says: define your crew. Swarm says: define your handoffs. Anthropic says: describe the goal, and Claude will figure out the orchestration.

Whether that bet pays off depends on whether Claude's generated harnesses are good enough to trust without inspection. The Bun rewrite and the HN community's quality concerns suggest they are not — yet. But the trajectory points toward a world where writing orchestration code is as obsolete as writing CSS sprites.

For practitioners building agent systems today, the playbook is:

1. Start with adversarial verification on high-value, bounded tasks
2. Set aggressive session budgets until you understand your cost profile
3. Use predefined agents over inline for anything touching production code — you want the system prompts locked down
4. Monitor the four missing bugs, not the sixty-six found — what does your workflow miss?
5. Do not ship workflow-generated code without human review — the "slop debt" problem is real

The orchestration frontier is moving fast. We covered the broad landscape shift last week. Dynamic workflows are the most concrete implementation of where that shift is heading: from human-authored coordination to machine-authored coordination, with all the power and risk that implies.

Originally published at AgentConn