Skip to content
Skip to content

The Agent Writes the Orchestrator Now: Parallelism's Late-May Turn

• 5 min read

The most important agent shift of the last two weeks isn’t a smarter model. It’s a change in where the plan lives. For two years the agent loop was a single context window churning through tool calls one at a time. As of late May 2026, the loop got demoted: the model now writes a program that fans work out across a swarm of subagents, and the existing test suite — not the model’s confidence — decides when the work is done. Parallelism has become the agent’s primary scaling axis, and that change reaches all the way from research papers down to your monthly invoice.

Orchestration moved out of the context window

The clearest marker is Claude Opus 4.8 and Dynamic Workflows, shipped May 28. The headline isn’t the benchmark bump; it’s the execution model. In a Dynamic Workflow, Claude generates a JavaScript orchestration script and runs it. As MarkTechPost put it, “the plan moves into code, not Claude’s context window,” and “intermediate results live in script variables instead.” The runtime fans out up to 16 concurrent subagents and 1,000 total per run. Agents attack a problem from independent angles, other agents try to refute the findings, and the run iterates until answers converge.

This is a real architectural break from the ReAct-style loop. When the plan is code, the context window stops being the bottleneck for long tasks — you’re no longer paying to keep ten thousand tokens of intermediate reasoning alive across every step. The orchestration state lives in variables, and the model’s context stays focused on the next decision. It’s the difference between a person holding a checklist in their head and a person running a build script.

The proof point Anthropic leaned on is telling. Bun’s founder used Dynamic Workflows to port the entire Bun codebase — roughly 750,000 lines — from Zig to Rust in 11 days, landing at a 99.8% test pass rate. The framing in the announcement matters more than the number: migrations run “from kickoff to merge, with the existing test suite as its bar.” The agent doesn’t decide it’s finished. The tests do.

The model is learning to do this internally, too

Orchestration-as-code is the engineering version of a move that research is making at the cognitive level: separate deliberation from action, and simulate before you commit. Thoughts-as-Planning (April 27) treats reasoning-chain optimization as sequential decision-making over a latent world model that simulates how edits to a reasoning chain change the output — so the agent can reason about consequences before executing. Efficient Agentic Reasoning Through Self-Regulated Simulative Planning (May 22) is even more on the nose: it decouples an internal simulative-planning phase from reactive execution and adds self-regulation — the agent decides how much planning a given step is worth instead of burning a fixed budget. Both echo the older Dyna-Think line of using world-model simulation to sharpen acting.

Put the two together and the pattern is consistent at every scale. Externally, the agent writes a script that spawns workers and checks their results. Internally, the model simulates candidate plans in a latent space and only acts on the survivors. Both are buying reliability by spending compute on planning and verification before spending it on irreversible action. That’s the same trade, whether the unit is a subagent or a token.

Fan-out is cheap to start and expensive to finish

Here’s the part the demos skip. A run that can spawn 1,000 agents has a cost curve that looks nothing like a chat session. Anthropic’s own warning is blunt: these features “consume meaningfully more tokens than a typical session,” and “costs climb fast.” And the timing is not a coincidence — three days after Dynamic Workflows, on June 1, GitHub Copilot moved every plan to usage-based billing. Usage is metered in AI Credits (one credit = $0.01) against per-model token rates, and agentic, multi-step sessions are explicitly called out as the high-consumption case. Developers drained monthly allotments in hours and the backlash was immediate.

The economics and the architecture are the same story told twice. When an agent’s main lever is fan-out, the binding constraint stops being model capability and becomes two things you control: the quality of your verification harness and your token budget. This is why “the test suite is the bar” isn’t a nice-to-have — it’s the only thing that makes a metered swarm finite. Without a hard acceptance gate, parallel agents will happily spend your budget refuting each other forever. The test suite is simultaneously the safety rail and the stop condition.

The practical takeaway for anyone building on this: before you reach for hundreds of parallel subagents, ask whether your task has a cheap, trustworthy oracle. A codebase with a real test suite does. A research question with no ground truth does not — and that’s exactly where fan-out turns into an expensive way to generate confident noise. Parallelism scales the work. Only verification scales the trust.

Worth bookmarking

Suggest changes