A harness for every task: dynamic workflows in Claude Code

Thariq Shihipar and Sid Bidasaria (Anthropic, Claude Code team) · article · 2026-06-02 source ↗ Reader 🖥️

Agent Coordination Overhead (Supervisor vs. Workflow)Agent Harness Agent Security Agent Context Files (CLAUDE.md / AGENTS.md)Context Rot & Context Limits Multi-Agent Orchestration AI Workflow Patterns

Because a single, continuously-running context window degrades on long, parallel, structured, or adversarial tasks through three specific failure modes — agentic laziness, self-preferential bias, and goal drift — Claude Code should let the model write and orchestrate a custom, task-specific multi-agent harness (a dynamic workflow) on the fly, rather than relying on one generic static harness for every task.

practical · expository — A product feature explainer written by its own authors: describes what dynamic workflows are, why they exist (three named failure modes of single-context execution), and a catalog of reusable composition patterns and use cases.

Structure

Part	Role
Example prompts across technical and non-technical tasks	concrete orientation before the mechanism
How dynamic workflows work (JavaScript harness, subagent spawning/coordination, model/isolation choice, resumability)	mechanism
Three named failure modes of single-context execution (agentic laziness, self-preferential bias, goal drift)	the problem dynamic workflows solve
Dynamic vs. static workflows	contrast with the prior approach (Agent SDK / claude -p scripted orchestration)
Six composable patterns (classify-and-act, fan-out-and-synthesize, adversarial verification, generate-and-filter, tournament, loop-until-done)	reusable vocabulary for building workflows
Eleven use cases (migrations, deep research, deep verification, sorting, memory/rule adherence, root-cause investigation, triage at scale, exploration/taste, evals, model routing)	evidence of generality beyond coding
When not to use dynamic workflows, token budgets, saving/sharing	qualification and operational guidance

Key terms

dynamic workflow
A custom multi-agent harness that Claude itself writes at runtime, as a JavaScript file with special functions for spawning and coordinating subagents, tailored to the specific task at hand.
agentic laziness
Claude stopping before finishing a complex, multi-part task and declaring the job done after only partial progress (e.g. 35 of 50 items in a security review).
self-preferential bias
Claude's tendency to prefer its own results or findings, especially when asked to verify or judge them against a rubric.
goal drift Agent Security
The gradual loss of fidelity to the original objective across many turns, especially after compaction, because each lossy summarization step can drop details like edge-case requirements or explicit 'don't do X' constraints.
quarantine (triage pattern)
Barring the agents that read untrusted public content from taking high-privilege actions themselves; those actions are instead performed by separate agents that only act on the (already-read) information.

Propositions

explicitcorroboratedClaude Code can now write and orchestrate its own custom multi-agent harness at runtime — a dynamic workflow — tailored to a specific task, rather than relying only on the one generic default harness.conf: high
supports ←Developer Newsletter: New models, Claude Tag, and dynamic workflows · p1 — This newsletter item is the release announcement for exactly the capability that sibling extraction analyzes in depth — Claude Code writing and orchestrating its own task-specific multi-agent harness at runtime.
explicitLong-running, massively parallel, highly structured, or adversarial tasks executed inside a single context window break down through three specific failure modes: agentic laziness, self-preferential bias, and goal drift (worsened by lossy compaction across many turns).conf: high
extendsThe New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p7 — new-sdlc frames the harness (not the raw model) as what dominates agent reliability; this article names the specific single-context failure modes (laziness, self-preferential bias, goal drift) that a better harness — here, a dynamic workflow — is built to counter.
explicitOrchestrating separate Claude subagents with their own context windows and focused, isolated goals is what combats agentic laziness, self-preferential bias, and goal drift — not better prompting within one context.conf: high
supportsNo Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p6 — Both independently converge on the same prescription — sub-agents exist strictly to isolate/compress context for a focused goal — from different sources (a practitioner talk vs. the Claude Code team's own product writeup).
extendsHow Claude Code works in large codebases: Best practices and where to start · p5 — Large-codebases piece frames skills as solving the scaling problem of loading only task-relevant specialized expertise; this article generalizes the same bounded-context principle into a full runtime-composed multi-agent harness, not just selective skill loading.
explicitStatic workflows (built with the Claude Agent SDK or `claude -p`) must be generic because they need to handle all edge cases in advance; dynamic workflows are possible now because the underlying model (Claude Opus 4.8) is capable enough to write a harness custom-built for one specific use case instead.conf: high
explicitComparative/pairwise judgment (tournaments, pairwise-comparison pipelines, bucket-rank-then-merge) is more reliable than absolute scoring for sorting large item sets, because trying to score 1000+ rows in one prompt degrades quality and exceeds context.conf: high
explicitA triage-at-scale workflow should quarantine agents that read untrusted public content from taking high-privilege actions, delegating those actions to separate agents that act only on the already-extracted information.conf: high
explicitA team's recurring corrections (from session histories or code-review comments) can be mined by parallel agents, adversarially verified ('would this rule have prevented a real mistake?'), and distilled into CLAUDE.md rules — and the reverse workflow (checking existing CLAUDE.md rules against a skeptic-persona subagent) is equally viable.conf: high
supportsHow Claude Code works in large codebases: Best practices and where to start · p4 — Both describe the same self-improving loop — mining sessions/corrections to update CLAUDE.md — via different mechanisms (a stop hook there, an explicit mining workflow here); convergent evidence for 'self-updating context files' as an emerging pattern.
explicitDynamic workflows use significantly more tokens than the default harness, so they are best reserved for complex, high-value tasks rather than default/regular coding tasks — the operative question is 'does this really need more compute?'conf: high
explicitA classifier agent can route a task to a different model (e.g. Sonnet vs. Opus) based on researched task complexity rather than a fixed, pre-assigned model choice.conf: high
supportsThe New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p13 — Both describe routing tasks to different models (Sonnet vs. Opus) by researched complexity/cost rather than a fixed assignment — the same mature-practice pattern named independently.
implicitTreating agentic laziness, self-preferential bias, and goal drift as solvable primarily by subdividing context across isolated subagents implicitly assumes these are context-scale/architectural problems, not deeper evaluation or alignment limitations that would persist inside each subagent's own isolated context too.conf: medium
implicitAdversarial verification is presented as a structural fix for self-preferential bias, which implicitly assumes a separate verifier agent (built from the same underlying model and training) is independent enough from the generating agent to catch bias the article says the model exhibits by default.conf: medium

Arguments

Use dynamic, task-specific multi-agent workflows instead of one generic harness for long-running, parallel, structured, or adversarial tasks. strength: high

Explicit premises:

Single-context execution degrades via three named failure modes on such tasks (agentic laziness, self-preferential bias, goal drift)
Separate subagents with their own context windows and focused goals combat those failure modes
A sufficiently capable model (Opus 4.8) can now write a custom harness per task rather than needing a generic, pre-built static one

Implicit premises:

Context-window isolation is sufficient to prevent the three failure modes from recurring within each isolated subagent, rather than merely relocating them to a smaller scope
The additional token/compute cost of running multiple subagents is justified whenever a task is 'complex' or 'high value,' a threshold the article leaves to the user's judgment rather than defining

Inferences:

If the isolation fix is only partial (subagents can still be individually lazy, self-preferential, or drift within their own context), then workflows raise the ceiling on task complexity handled but don't eliminate the need for verification/review of subagent output — which the article's own 'adversarial verification' pattern tacitly concedes

Narratives

Bun was rewritten from Zig to Rust using dynamic workflows: breaking the migration into per-callsite/per-failing-test/per-module steps, spinning off a subagent per fix in its own worktree, then having another agent adversarially review and merge.
→ Demonstrates the fan-out-and-synthesize plus adversarial-verification patterns applied to a real, large-scale production migration, grounding the abstract patterns in a concrete, high-stakes example.

Questions addressed

✅ Why does a single Claude Code context window break down on certain task types?
Three specific failure modes: agentic laziness, self-preferential bias, and goal drift (compounded by lossy compaction).
⭕ Does isolating work into separate subagent context windows actually eliminate these failure modes, or just relocate them to a smaller scope?
Not addressed; the article asserts isolation 'combats' the failure modes without examining whether an individual subagent can still exhibit the same laziness/bias/drift within its own window.
⭕ How should a team govern a growing library of saved, shared dynamic-workflow JavaScript files once many engineers are writing their own?
Only a mechanical answer is given (save to ~/.claude/workflows, or distribute via a skill, treating the workflow as a template); no discussion of review, ownership, versioning, or conflict across a team's accumulated workflows.

Gaps

incompleteNo governance or review model is described for a team's growing collection of saved dynamic-workflow scripts. As engineers independently write and save JavaScript harnesses (to ~/.claude/workflows or bundled into skills), the article doesn't address ownership, versioning, duplicate/competing workflows for the same task, or how a team avoids the exact 'good setups stay tribal' proliferation problem this corpus has already flagged for skills and CLAUDE.md rule libraries.
Read next: Read extract-claude-code-in-large-codebases on why plugins exist specifically to solve the 'good setups stay tribal' organizational problem for skills/hooks/MCP bundles, and ask whether dynamic workflows need the same organizational answer (a dedicated owner, a shared workflow registry) rather than just a file-save mechanism.
illogicalThe quarantine pattern for triage workflows (barring agents that read untrusted content from high-privilege actions) is stated as a one-line mitigation without specifying the enforcement mechanism: how is the boundary between 'reads untrusted content' and 'acts' actually enforced so that instructions smuggled inside the untrusted content cannot still reach the acting agent through the extracted summary it's handed?
Read next: Look for prompt-injection and tool-permission-boundary literature specifically addressing information flow between an agent that reads untrusted content and a separate agent that acts on its output, not just role separation by convention.
incompleteAdversarial verification is prescribed as the fix for self-preferential bias, but the article never asks whether a verifier agent built from the same model family is independent enough to catch bias the article itself says the model exhibits by default when judging its own work.
Read next: Look for research on cross-model or cross-family verification (a different model judging another's output) versus same-model adversarial verification, to test whether same-family verifier agents actually reduce self-preferential bias or merely add a second biased opinion.