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.

View original post on X →

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 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" }
);

Boris Cherny from the Claude Code team announced the research preview in May with 10,000+ likes — the engagement suggested developers had been waiting for exactly this primitive:

View original post on X →

---

Six Workflow Patterns

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

Pattern	What It Does	When to Use It
Classify-and-act	Route items to specialized handlers	Mixed-type inputs (bugs, features, docs)
Fan-out-and-synthesize	Parallel work + barrier + merge	Independent subtasks (file audits, research)
Adversarial verification	Second wave refutes first wave	High-stakes decisions, code review
Generate-and-filter	Produce many candidates, select best	Creative tasks, solution search
Tournament	Pairwise judging until winner emerges	Ranking, selection from alternatives
Loop until done	Iterate with quality check each round	Convergent tasks (optimization, cleanup)

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.

Thariq Shihipar from Anthropic framed the core concept — Claude building its own “harness” for each task — and the framing stuck:

View original post on X →

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:

View the full article on Latent Space →

---

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.

View the full article on AlphaSignal →

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.

---

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.

The agent can use predefined agents (saved configurations with their own model, system prompt, and tools) or inline agents (defined on the fly by the workflow). You can list up to 20 predefined agents per workflow, and an inline agent inherits the session agent’s model and tools.

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.

View the full discussion on Hacker News →

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.

---

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:

Feature	Claude Dynamic Workflows	LangGraph	CrewAI	OpenAI Swarm
Orchestration	Runtime-generated JS	Static graph	Role-based agents	Function handoffs
Harness	Disposable, per-task	Persistent graph	Persistent crew config	Persistent routes
Max agents	1,000 per run	No hard limit	No hard limit	No hard limit
Concurrency	64 (API), 16 (CLI)	Executor-dependent	Sequential default	Sequential
Mid-run steering	Not supported	Checkpoints	Supported	Supported
Model lock-in	Claude only	Any LLM	Any LLM	OpenAI only

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. This means:

• No framework lock-in accumulates. You are not maintaining a DAG definition or crew configuration.
• The harness matches the task exactly. A security audit gets a different structure than a migration.
• But you cannot inspect or modify the harness before it runs (in Managed Agents). Claude Code lets you review it.

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 API in Practice

For teams ready to integrate, here is what the Managed Agents setup looks like. You need three things:

1. Create predefined agents (optional but recommended for control):

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 the 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 a session and send work:

session = client.beta.sessions.create(
    agent=lead_agent.id,
    environment_id=environment.id,
)

# The agent decides whether to use a workflow
response = client.beta.sessions.send_message(
    session_id=session.id,
    message="Audit this repository for security vulnerabilities.",
)

---

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.

---

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.

---

For more on multi-agent systems and fleet orchestration patterns, follow AgentConn.