Dynamic Workflows: 231-Day Migration, 13 Days

On May 28, Anthropic shipped three things simultaneously: Claude Opus 4.8, dynamic workflows in Claude Code, and a case study that stopped the scrolling — a Salesforce team that compressed a 231-person-day migration into 13 calendar days.

The X post announcing dynamic workflows hit 10.2K likes and 3.4M views, making it the highest product-engagement tweet of the day. The reactions weren’t about the model. They were about the harness.

That distinction matters. The unit of competition in agentic coding has moved from the model to the orchestration layer. Dynamic workflows are Anthropic’s answer to the question every operator has been asking since Claude Code launched: what happens when the task is too big for one agent?

What Dynamic Workflows Actually Are

A dynamic workflow is not a prompt chain. It’s not a loop. It’s a JavaScript orchestration script that Claude writes for your task and a runtime executes in the background.

When you trigger a workflow — either by asking Claude directly or enabling the ultracode setting — Claude plans dynamically based on your prompt, breaks it into subtasks, and fans the work across tens to hundreds of parallel subagents. The key architectural decision: the orchestration plan lives in the script, not in the model’s context window. That’s what makes a 500-agent run feasible.

Three primitives, each for a different problem shape:

• Dynamic Workflows — machine-determined orchestration for large, unstructured problems. Claude autonomously partitions work and drives convergence. Up to 1,000 subagents, 16 concurrent.
• Subagents — human-directed parallelization for well-defined, repeatable tasks. Read-only and general-purpose variants with isolated context windows.
• Agent Teams — collaborative multi-agent coordination via shared git repositories. Members claim tasks, merge continuously, resolve conflicts automatically.

Progress saves automatically. Interrupted jobs resume rather than restart. An adversarial verification layer spawns independent agents to refute findings before delivery.

The Salesforce Playbook: 33 Endpoints in 13 Days

The headline number — 231 person-days compressed to 13 — deserves unpacking. The team faced a migration of 33 API endpoints to a new cloud-native architecture. Here’s how they did it.

Step 1: Build the rule set. The team created a rule-based framework using Markdown files combined with reference implementations. These weren’t prompts — they were constraints. Each file specified exactly how an endpoint should be migrated, with working code as the baseline.

Step 2: Autonomous loops. They let LLM loops run build-fix-validate cycles without manual intervention. Each iteration caught errors, fixed them, and re-validated against the test suite.

Step 3: Parallel isolation. Migrations ran across isolated environments, generating multiple PRs simultaneously. The largest single PR delivered 21 endpoints with complete test coverage.

Step 4: Feedback integration. Each round of PR review feedback was incorporated back into the rule set. As Tallapragada put it: “Each round of PR feedback was fed back into the rule set, so accuracy kept improving.”

The result: 5 total PR submissions, 33 endpoints migrated, 18x speed improvement.

Salesforce’s broader metrics (April 2026 vs. 2025): completed work items per developer +50.8%, merged PRs per developer +79%, “Effective Output Score” +151.3%, incidents -5%.

The Bun Migration: 750K Lines in 11 Days

If Salesforce is the enterprise proof point, the Bun Zig-to-Rust migration is the frontier demo. Jarred Sumner used dynamic workflows to port roughly 750,000 lines from Zig to Rust with 99.8% of the existing test suite passing — eleven days from first commit to merge.

The workflow ran in four phases:

1. Lifetime mapping — one workflow mapped the correct Rust lifetime for every struct field in the Zig codebase
2. Parallel porting — hundreds of agents wrote .rs files as behavior-identical ports of .zig counterparts, with two reviewers checking each file
3. Fix loop — a build-and-test loop ran until both compiled clean
4. Cleanup — agents identified unnecessary data copies and optimized

The numbers from the merged PR: PR #30412, 6,755 commits, 2,188 files changed. Anthropic notes this is not yet in production — it’s a proof of concept at a scale no single-agent loop could reach.

Ultracode: The Operator Setting

Most developers won’t invoke workflows manually. The practical interface is ultracode — a session-level setting accessible through the effort menu that combines xhigh reasoning effort with automatic workflow activation.

When ultracode is on, Claude decides on its own whether a given task warrants spinning up workflow machinery. Simple tasks get single-agent execution. Complex tasks trigger automatic orchestration.

Ken Huang’s analysis on the Agentic AI Substack frames the strategic positioning well: “At enterprise scale it is a cost and quality decision” which execution model to employ. The three primitives — workflows, subagents, agent teams — aren’t competing features. They’re different tools for different problem shapes.

The Cost Equation

Dynamic workflows consume substantially more tokens than typical Claude Code sessions. A codebase-wide audit that would take 10K tokens in conversation might use 100K+ in a workflow. MarkTechPost’s coverage notes the 1,000-subagent cap and the fact that Enterprise plans have workflows disabled by default — admins must explicitly opt in.

This is a real consideration for operators building agentic pipelines. The ROI calculation is straightforward when you’re compressing months of work to days (Salesforce). It’s less clear for routine tasks where single-agent execution suffices.

How It Compares: Codex, Gemini, and the Orchestration Gap

OpenAI’s Codex and Google’s Gemini Code Assist both offer agentic coding capabilities, but neither has shipped an equivalent to dynamic workflows. Codex operates as a cloud-first asynchronous agent — you assign a task, it runs in a sandbox, and delivers results. Gemini Code integrates deeply into the Google Cloud developer workflow. Both are single-agent architectures at their core.

The dynamic workflows distinction is the multi-agent orchestration layer: the ability to fan out to hundreds of independent agents, have adversarial verifiers check their work, and converge on a result — all within a single session. This is architecturally different from running multiple Codex tasks in parallel, because the orchestration plan itself is machine-generated and adaptive.

TechCrunch noted that Opus 4.8 shipped just 41 days after Opus 4.7 — a notably accelerated release cycle that suggests Anthropic is prioritizing the harness layer alongside model improvements. The release addressed community concerns about Opus 4.7’s reception by pairing model improvements with concrete workflow capabilities.

The convergence report for May 30 — our cross-source signal analysis — gives additional context. The HN discussion on dynamic workflows ran alongside an “Ask HN” thread where developers shared early results: autonomously landing 20+ optimizations reducing Claude Code’s token usage by ~15%, and porting modules to TypeScript without manual intervention.

The Harness War

The convergence report for May 30 — our cross-source signal analysis — identified agentic-coding tooling as the third most convergent cluster of the day, appearing across GitHub, YouTube, X, and Substack simultaneously.

The pattern is telling: GitHub Trending is saturated with agent infrastructure. ECC for harness optimization. cc-switch and ccx for multi-agent CLI switching between Claude, Codex, and Gemini. opencode. herdr. Multiple trending repos exist purely to switch between coding agents, which means no single agent has locked in the developer.

The moat is shifting to whoever owns the orchestration layer. Dynamic workflows are Anthropic’s play for that layer — and the Salesforce partnership signals that enterprise is buying in.

The Operator Playbook

For teams evaluating dynamic workflows:

1. Start with rule sets, not prompts. Salesforce’s success came from Markdown constraint files with reference implementations — not prompt engineering.
2. Use isolated environments. Parallelization requires isolation. Each agent needs its own sandbox to generate PRs without conflicts.
3. Feed back PR reviews. The compounding improvement loop — review → rule set update → better accuracy — is the mechanism that makes each subsequent migration faster.
4. Know the cost curve. Workflows are high-token-count operations. Run the ROI calculation on time saved vs. tokens consumed before committing to workflow-based pipelines.
5. Default to ultracode for complex tasks. Let Claude decide when orchestration is warranted rather than manually managing workflow triggers.

Dynamic workflows are available in research preview across the Claude Code CLI, Desktop, VS Code extension, the API, Amazon Bedrock, Vertex AI, and Microsoft Foundry. Max and Team plans have workflows on by default.

Resources: The official documentation for dynamic workflows is at code.claude.com/docs/en/workflows. Anthropic’s announcement post with the Bun and Salesforce case studies is at claude.com/blog.