DEV Community

Cover image for Orchestration Ate the Moat: Anthropic's Agent Swarm
Max Quimby
Max Quimby

Posted on Originally published at agentconn.com

Orchestration Ate the Moat: Anthropic's Agent Swarm

Orchestration Ate the Moat: Anthropic's Agent Swarm

On October 9, Anthropic opened dynamic workflows in Claude Managed Agents as a public beta. A single workflow run can now spawn up to 1,000 agents — with 64 threads running concurrently — and a lead agent writes the coordination program that distributes work, collects results, and manages information flow across all of them. This is not a research demo. It ships behind a single API flag (multiagent_20261001), and Anthropic's own planted-bug benchmark claims a dynamic workflow found 66 out of 70 bugs in a 116,000-line codebase, compared to 14-27 for a single agent.

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

The same week, Latent Space published a deep dive on how CJ Avilla and Harrison Stall — Members of Technical Staff at Anthropic — described the architecture at AI Engineer New York. GitHub Trending is essentially an agent-tooling showcase: RE agents, pentesting agents, context-window managers, video renderers for agent output. And YouTube's extended tier is wall-to-wall "personal agent boards of advisors." The convergence is unmistakable: the frontier has shifted from single-agent capability to coordination infrastructure.

Latent Space article — How Anthropic's Dynamic Workflows Coordinate Claude Agents

View the full article on Latent Space →

This article maps what the orchestration layer actually has to solve, why Anthropic's implementation matters, and what it means for teams building agent systems today.

The Context Window Problem That Created Orchestration

The simplest argument for multi-agent coordination is that single agents degrade as their context fills up. Addy Osmani made this case in February 2026: what started as developers discovering feature-flagged multi-agent capabilities in Claude Code's binary and building workarounds with subagents and bash scripts became a first-class feature because LLMs demonstrably perform worse as context expands.

Addy Osmani's Claude Code Swarms post

View the full post on Addy Osmani's blog →

This is not a theoretical concern. When a single agent runs a codebase-wide migration, every intermediate result — every file read, every grep, every sub-task finding — lands in its context window. By file 50, the agent is swimming in 100K+ tokens of prior context, and its accuracy on file 51 is measurably worse than on file 1.

Dynamic workflows solve this by moving the coordination loop outside the model's context entirely. Claude writes a JavaScript orchestration script — the plan, the branching logic, the agent-count decisions, the verification passes — and a background runtime executes it. The model's context window only receives the final synthesized answer. As InfoQ reported, "loops, branching, agent-count decisions, verification passes — all live in JavaScript variables, outside Claude's context window."

💡 Key architectural insight: Dynamic workflows separate the coordination plane from the execution plane. The lead agent plans and writes the coordination program. Subagents execute tasks in isolation. Results flow back through the script, not through the model's attention mechanism. This is what makes orchestration scale — the coordinator's context stays small regardless of how many agents it manages.

What Dynamic Workflows Actually Are

Anthropic's orchestration comes in two forms, and the distinction matters:

Claude Code Dynamic Workflows (launched May 28, 2026, alongside Opus 4.8) — the CLI version. Claude writes a JavaScript script using primitives like agent(), parallel(), and pipeline(). The script coordinates tens to hundreds of subagents in a single session. Initially a research preview, now generally available. You trigger it by asking Claude to "use a workflow" or enabling the ultracode setting.

Managed Agents Dynamic Workflows (public beta October 9, 2026) — the hosted API version. Same concept, server-side execution. A developer sets the agent's multiagent field to multiagent_20261001, and the lead agent writes and executes the coordination program in the cloud. Up to 1,000 agents per run, 64 concurrent threads.

The Decoder coverage — Anthropic's Claude can now orchestrate up to 1,000 AI agents

View the full article on The Decoder →

The key innovation in both: Claude decides the structure. Previously, developers had to manually configure a coordinator and a roster of subagents. With dynamic workflows, the lead agent plans the work, then writes the orchestration program. Optional pre-configured specialist subagents can be passed in, but the coordination logic is generated, not hardcoded.

At AI Engineer New York, Anthropic's Harrison Stall called these flows "the next version of multi-agent orchestration" and framed the ambition as applying more test-time compute to hard problems, with the goal of making scientific progress broadly accessible.

The Hacker News thread on Claude Managed Agents (169 points) captures the practitioner reaction — a mix of genuine excitement about the API design and skepticism about whether orchestration overhead justifies the token cost for most workloads.

Hacker News thread on Claude Managed Agents — 169 points

View the discussion on Hacker News →

When Anthropic later shipped the multiagent orchestration update — adding dreaming, outcomes, and dynamic workflows to Managed Agents — the thread focused on whether self-improving agents via "dreaming" were genuinely useful or just marketing language for context summarization.

Hacker News thread on multiagent orchestration — dreaming, outcomes, and dynamic workflows

View the discussion on Hacker News →

The Bun Rewrite: 750,000 Lines in Eleven Days

Anthropic's most dramatic case study is Jarred Sumner's use of dynamic workflows to port Bun from Zig to Rust. The numbers reported in Anthropic's official launch post:

  • 750,000 lines of Rust generated
  • 99.8% of the existing test suite passing
  • Eleven days from first commit to merge

One workflow mapped Rust lifetimes for struct fields. Hundreds of agents then ported each .zig file to .rs, with two reviewers per file. A fix loop ran the build and tests until both passed. An overnight workflow reduced unnecessary data copies and opened a PR per change.

⚠️ Contrarian Corner: These numbers are impressive but come entirely from Anthropic's launch post and have not been independently verified in production. A senior OpenAI engineer called agent swarms "a massive waste of tokens." The planted-bug benchmark (66/70 vs 14-27) lacks a cost-matched comparison — if the swarm used 50x the tokens, a single agent with 50x the budget might perform comparably. For most production workloads, a single well-prompted agent with good tools still beats a poorly-orchestrated swarm.

The Five Problems Every Orchestration Layer Must Solve

Whether you are using Anthropic's dynamic workflows, LangGraph, CrewAI, or Microsoft's Agent Framework, your orchestration layer faces the same five architectural challenges:

1. Fan-Out Strategy

How do you decompose a task into parallelizable subtasks? This is harder than it sounds. Not every task decomposes cleanly — sequential dependencies, shared data, and implicit ordering constraints mean that naive parallelization can produce worse results than sequential execution.

Anthropic's approach: the lead agent writes the decomposition plan as code. It decides how many agents to spawn and what each one does. Stall's advice at AI Engineer NYC was to start with lower defaults and explicitly encourage parallelization for ambitious tasks — models tend to be conservative about fanning out.

2. Shared State

Subagents in Anthropic's system share a filesystem but cannot directly message each other through the API. This is a deliberate design choice: it avoids the complexity of peer-to-peer agent communication while still allowing agents to coordinate through files.

The trade-off is real. Latent Space's "Zawinski's Law of MultiAgents" argues that "every agent attempts to expand until it can message other agents." The pressure toward direct agent-to-agent communication is strong, and Claude Code's August 2026 addition of session-to-session messaging hints at where this is heading. But for now, the filesystem-as-shared-state pattern keeps the system tractable.

3. Adversarial Verification

This is where dynamic workflows diverge most sharply from simple fan-out. Anthropic's system does not just parallelize — it verifies. Second-wave agents attempt to refute first-wave findings, and only results that survive the adversarial pass make it to the final output.

This pattern — generator agents plus evaluator agents running in tandem — was also the focus of Anthropic's workshop at AI Engineer Europe 2026. It is the agent judge layer scaled to run within a single workflow execution.

4. Cost Control

Workflows multiply token consumption. Anthropic's own documentation warns that dynamic workflows "can use substantially more tokens than a typical session" and recommends starting with scoped tasks. The model itself does not know its budget while running — Stall said that telling models their budget "could make them a little bit anxious."

The cost question is the key objection to agent swarms. One practitioner guide warns that switching to Opus 4.8 for a 500-agent audit can change the bill by an order of magnitude. The Opus-plans-haiku-executes pattern — where a capable model orchestrates while cheaper models execute — is becoming the default cost mitigation strategy.

5. Graceful Degradation

What happens when agents fail mid-swarm? Anthropic's design saves progress, so interrupted jobs resume rather than restart. Individual agent failures do not take down the workflow. But the failure semantics of a 1,000-agent run are fundamentally different from a single-agent session — you need monitoring, kill switches, and isolation between agent workspaces.

This is why git worktrees became the enabling infrastructure for parallel agent coding. Each agent works in its own worktree, so one agent's bad merge does not contaminate another's working directory.

The OSS Orchestration Saturation Wave

Anthropic is not building in a vacuum. The open-source layer is converging on the same problems:

LangGraph leads with a graph-based state-machine approach, durable execution via PostgresSaver, and time-travel debugging. It is verbose — a simple two-agent flow still requires a state schema, nodes, edges, and compilation — but it has the largest verified enterprise deployment list.

CrewAI optimizes for prototype velocity with role-driven Python agents. MIT-licensed, quick to start, weaker for production durability.

Microsoft Agent Framework (MAF) is the unified successor to AutoGen and Semantic Kernel, reaching GA in April 2026 with native MCP and A2A protocol support. The .NET and Python SDKs are MIT-licensed.

Sakana AI is pushing multi-agent coordination in a different direction entirely. Their MASS (Multi-Agent Self-Supervision) framework uses collective intelligence for recursive self-improvement — agents coordinating not just to complete tasks, but to improve themselves.

@hardmaru announcing Sakana AI's MASS paper

View original post on X →

The companion blog post dives into the technical details of how collective intelligence enables recursive self-improvement — a coordination pattern that goes beyond task completion into capability expansion.

@hardmaru sharing the MASS blog post

View original post on X →

And at the practitioner level, the pattern is everywhere. YouTube creators are building multi-agent advisory boards as personal productivity tools. AI Engineer conference talks are wall-to-wall production orchestration stories — from Flywire running agents in regulated finance to Rexmore's three-level review architecture.

GitHub Trending tells the same story from the supply side. Today's trending page features reverse-engineering agents (morluto/rea at 199K stars), autonomous pentesting agents (pentagi at 28K), context-window optimizers for agents (context-mode at 28K), and video renderers for agent output (hyperframes at 62K). The pattern the convergence report identified — "every other repo is an agent, a tool for agents, or infra agents consume" — is visible in the raw data.

💡 The GitHub signal: Agent-adjacent infrastructure repos now routinely hit 50K-200K stars within weeks. The supply of orchestration tooling is growing faster than the demand for it. Most teams building with agents today will not need to build their own orchestration layer — they will pick from five competing frameworks. The question is which five problems (fan-out, state, verification, cost, degradation) the framework handles well.

The Pattern Goes Mainstream

The clearest signal that orchestration has moved from research to infrastructure is what is happening on YouTube. This week alone, Nate Herk published a walkthrough of building an "AI Board of Advisors" — multiple Claude agents with different expertise areas coordinating to analyze decisions. It is not a research prototype. It is a Claude skill that anyone can install.

Databricks launched Agent Bricks — an agent developer platform that treats orchestration as a first-class platform concern, not a library import. The framing has shifted from "how do I build an agent" to "how do I build a platform that manages agents."

The trajectory is clear: orchestration is commoditizing. Within a year, running a multi-agent workflow will feel as routine as running a CI pipeline. The competitive differentiation will not be in the orchestration framework itself — it will be in how well you define the task decomposition, the verification criteria, and the cost controls for your specific domain.

What This Means for You

If you are building agent systems in Q4 2026, here are the concrete implications:

Evaluate orchestration frameworks against the five problems, not benchmarks. Every framework will show you a demo that works. Ask instead: how does it handle fan-out for tasks with sequential dependencies? What happens when agent 47 of 100 fails? Can you set per-agent token budgets? Can you inspect what each agent did and why?

Start with native orchestration before reaching for a framework. If you are already on Claude, dynamic workflows (ultracode or the managed agents API) handle the common patterns — fan-out/synthesize, adversarial verification, tournament — without adding a dependency. You only need LangGraph or CrewAI when you need cross-model orchestration, durable multi-session workflows, or custom state machines.

The cost conversation is real. A 1,000-agent workflow that each consumes 10K tokens costs you 10M tokens. At current API pricing, that is a meaningful bill for a single task execution. The Opus-plans-haiku-executes pattern — smart orchestrator, cheap workers — is not optional at scale.

Verification is the feature, not parallelism. The reason dynamic workflows found 66/70 bugs while a single agent found 14-27 is not just that more agents looked at more code. It is that adversarial agents verified findings, and only surviving results made the cut. If your orchestration layer just fans out without verifying, you are paying for parallelism without getting reliability.

The harness still matters more than the model. Orchestration is the harness at scale. SWE-bench Pro showed rank correlations of -0.05 across different harnesses — meaning the same model can rank first or last depending on how it is orchestrated. The orchestration layer is not a nice-to-have on top of a good model. It is what makes the model good.

The single-agent era lasted about a year. The fleet management era started in June. The orchestration-as-infrastructure era started this month. The frontier moved, and it moved to coordination.

Originally published at AgentConn

Top comments (0)