Dynamic Workflows: The Bridge Between Three Ecosystems

Source: DYNAMIC_WORKFLOWS_RESEARCH.md (2026-07-22) Releases: Claude Code v2.1.154+ (May 26, 2026) Cross-references: co-fita-harness, co-fita-orchestrator, co-fita-governance, unit-distance-methodology

What Are Dynamic Workflows

Dynamic Workflows represent a paradigm shift in Claude Code's orchestration model. Rather than having Claude plan and execute within a single context window, Dynamic Workflows allow Claude to write a JavaScript orchestration script on the fly that spawns and coordinates dozens to hundreds of subagents, each with isolated context windows. The runtime executes this script in the background while the user's session stays responsive.

The orchestration plan moves from Claude's context window into executable JavaScript code. This solves three systemic failure modes of single-context agentic work:

Failure Mode	Dynamic Workflows Solution
Agentic laziness -- Claude stops before finishing and declares victory	Deterministic JS script enforces completion of all subtasks
Self-preferential bias -- Claude is lenient on its own results	Separate verifier agents with isolated contexts judge independently
Goal drift -- gradual loss of fidelity across turns	Script encodes the original objective; agents receive focused, isolated goals

graph TB
    subgraph "User Session"
        U[User Prompt] --> C[Claude Main Context]
        C --> W[Workflow Script Generated]
        C --> R[Report Received]
    end

    subgraph "Workflow Runtime (Background)"
        W --> RT[JavaScript Runtime]
        RT --> A1[Agent 1]
        RT --> A2[Agent 2]
        RT --> A3[Agent N...]
        RT --> SYN[Synthesis / Barrier]
        A1 --> SYN
        A2 --> SYN
        A3 --> SYN
        SYN --> R
    end

    subgraph "Agent Isolation"
        A1 --> CW1[Own Context Window]
        A2 --> CW2[Own Context Window]
        A3 --> CW3[Own Context Window]
    end

Architecture and Execution Model

Core Properties

Property	Detail
Intermediate results	Live in script variables, not Claude's context
Script persistence	Written to `~/.claude/projects/<session>/`
Resumability	Within same session (not across sessions)
Mid-run user input	Not supported (only permission prompts can pause)
Concurrency	Up to 16 concurrent agents
Total agents	Up to 1,000 per run
Model per agent	Inherits session model unless script routes differently

Script Primitives

The JavaScript runtime exposes a small, purpose-built API:

Primitive	Purpose	Co-Fita Equivalent
`agent(prompt, options)`	Spawns one subagent, returns result	`invoke_subagent` or Antigravity `define_subagent`
`pipeline(items, fn)`	Fan-out: one agent per item in a list	Orchestrator Phase II batch execution
`args`	Global variable for saved workflow parameters	Task spec in `state/task_spec.md`
`return`	Final result delivered to user session	Wiki export / Telegram notification
`JSON`, `Math`, `Array`	Standard JavaScript for data processing	Python stdlib in harness_core

Agent options:

Option	Effect
`label`	Display name in progress view
`schema`	JSON Schema for structured output
`model`	Override model for this specific agent
`isolation`	`"worktree"` for git-isolated execution

Permission Model

Workflow subagents always run in acceptEdits mode. File edits are auto-approved. Shell commands, web fetches, and MCP tools not in the allowlist can still prompt. This is analogous to Co-Fita's pattern where worker agents operate within scoped roles -- co-fita-governance enforces scope via proposal categories, while Dynamic Workflows enforce it via tool allowlists.

Lifecycle

stateDiagram-v2
    [*] --> Generated: Claude writes JS script
    Generated --> Approved: User approves plan
    Approved --> Running: Runtime executes
    Running --> Running: Agents spawned/completed
    Running --> Paused: User pauses (p)
    Paused --> Running: User resumes (p)
    Running --> Completed: All agents done
    Running --> Stopped: User stops
    Stopped --> Running: Resume with cached results
    Completed --> Saved: User presses 's'
    Saved --> [*]: Available as /name command

The 6 Named Patterns

Anthropic describes six orchestration patterns that Claude may compose when building workflows. Each implements a different state machine topology in JavaScript control flow.

1. Classify-and-Act

graph LR
    I[Input] --> CL[Classifier Agent]
    CL --> |Type A| A1[Agent A]
    CL --> |Type B| A2[Agent B]
    CL --> |Type C| A3[Agent C]
    A1 --> O[Output]
    A2 --> O
    A3 --> O

Topology: Router. Classify input, then route to specialized agents.

Co-Fita mapping: Phase I Ideation already classifies research angles before execution. In Dynamic Workflows, this becomes explicit routing logic.

2. Fan-out-and-Synthesize

graph LR
    I[Input] --> SPLIT[Split Tasks]
    SPLIT --> A1[Agent 1]
    SPLIT --> A2[Agent 2]
    SPLIT --> A3[Agent N...]
    A1 --> BARRIER[Barrier / Synthesize]
    A2 --> BARRIER
    A3 --> BARRIER
    BARRIER --> O[Output]

Topology: Fork-Join. Split task, run agents in parallel, barrier-wait, merge.

Co-Fita mapping: Phase II Execution could fan out across multiple approaches simultaneously instead of sequentially. The orchestrator currently tries one approach per iteration; a workflow could try all 3 in parallel.

Antigravity mapping: The Research Director spawning multiple hypothesis-verification subagents simultaneously is structurally identical.

3. Adversarial Verification

graph LR
    I[Input] --> G[Generator Agent]
    G --> V[Verifier Agent]
    V --> |Pass| O[Output]
    V --> |Fail| G

Topology: Pipeline with feedback. Generate, verify, accept or reject.

Co-Fita mapping: Phase III Red Team Audit. The RedTeamAuditor in co-fita-harness performs exactly this role -- checking for reward hacking (confidence 1.0) and steganography (confidence 0.85). In Dynamic Workflows, this pattern would use separate agent contexts for generator and verifier, eliminating the self-preferential bias problem.

Antigravity mapping: The CITATION-VERIFIER subagent role in the unit-distance research.

4. Generate-and-Filter

graph LR
    I[Input] --> G[Generate N ideas]
    G --> F1[Filter by rubric]
    F1 --> F2[Deduplicate]
    F2 --> F3[Verify quality]
    F3 --> O[Top M results]

Topology: Funnel. Generate many, filter to few.

Co-Fita mapping: The EloConsolidator in co-fita-governance already implements this as pairwise tournament debate. The Tournament pattern (below) is the Dynamic Workflow equivalent.

5. Tournament

graph TB
    I[Input] --> A1[Agent Approach 1]
    I --> A2[Agent Approach 2]
    I --> A3[Agent Approach 3]
    I --> A4[Agent Approach N]
    A1 --> J1[Judge: 1 vs 2]
    A2 --> J1
    A3 --> J2[Judge: 3 vs N]
    A4 --> J2
    J1 --> F[Final Judge]
    J2 --> F
    F --> O[Winner]

Topology: Bracket. N agents compete pairwise until a winner emerges.

Co-Fita mapping: The Elo tournament in consolidator.py (K-factor 32, promotion threshold 1200, minimum 3 matches). The key gap: Dynamic Workflows have no built-in Elo math. To replicate Co-Fita's tournament, the workflow script must implement pairwise judging with scoring logic in JavaScript.

Antigravity mapping: The ELO-RANKER subagent role that calibrated the unit-distance research hypotheses (Elo 1500 for H11 through Elo 2350 for H16).

6. Loop-Until-Done

graph LR
    I[Input] --> A[Agent: Do work]
    A --> C{Stop condition met?}
    C --> |No| A
    C --> |Yes| O[Output]

Topology: Cyclic with guard. Loop until quality stabilizes, no new findings, or no more errors.

Co-Fita mapping: The orchestrator's start_loop(max_iterations) is a fixed-iteration version. A true loop-until-done would replace the max_iterations=5 default with quality-convergence detection.

The `ultracode` Effort Level

ultracode is a Claude Code setting that combines xhigh reasoning effort with automatic workflow orchestration. When enabled, Claude plans a workflow for each substantive task without waiting for the user to ask.

Setting	Behavior
`/effort ultracode`	Per-session activation
`claude --effort ultracode`	Launch flag (v2.1.203+)
`ultracode: <task>`	Per-task opt-in keyword (previously `workflow:`)

With ultracode on, a single request can turn into several workflows in sequence: one to understand the codebase, one to make the change, one to verify it. Every task gets this treatment. Token usage increases significantly.

For Co-Fita: ultracode represents the point where Dynamic Workflows replace manual per-phase orchestration. Instead of Alefita directing each phase, ultracode would automatically generate workflows for Planning, Research, Implementation, Review, and Documentation -- with human chancela between phases.

State Machines in Dynamic Workflows

Dynamic Workflows do not provide a formal state machine abstraction. There is no state, transition, or onEnter/onExit API. The state machine is implicit in JavaScript control flow:

States = values of script variables at any point
Transitions = sequential/branching/looping logic
Guards = conditional expressions
Actions = agent() and pipeline() calls

This contrasts with explicit state machine tools (LangGraph, Temporal, AWS Step Functions):

Dimension	Dynamic Workflows	Explicit State Machines
Flexibility	Any topology possible	Constrained to defined states
Formality	Informal (JS variables)	Typed states and transitions
Visualization	None built-in	State diagrams generated automatically
Resumability	Coarse (completed agents cached)	Fine-grained (checkpoint at each state)

Comparison with Co-Fita: The co-fita-orchestrator implements an explicit 5-phase state machine (Ideation -> Execution -> Audit -> Fixation -> Governance). Dynamic Workflows would model each phase as a workflow invocation with the state machine encoded in the calling script.

Comparison with Antigravity: The Antigravity channel protocol (<|channel|>analysis<|/channel|>) provided structured separation between reasoning, analysis, and communication. Dynamic Workflows have no equivalent -- agent internal reasoning is opaque to the script, visible only through structured output schemas.

Three-Ecosystem Comparison

Co-Fita vs Dynamic Workflows vs Antigravity

Dimension	Co-Fita Orchestrator	Dynamic Workflows	Antigravity 2.0
Orchestration	Claude plans turn-by-turn within each phase	JavaScript script holds the plan deterministically	Main agent defines subagents inductively
Intermediate results	In Claude's context (task list state)	In script variables (invisible to Claude)	Brain artifacts per conversation
Human interaction	Human reviews at each phase boundary	No mid-run user input	Human directs via conversation
Reusability	Implicit in CLAUDE.md instructions	Saved `.js` scripts as `/commands`	Per-conversation artifacts
Scale	Few subagents per phase	Dozens to hundreds per run	Dozens of invocations per session
State persistence	Task list survives across turns	Script variables within run; agents cached	JSONL transcripts + markdown
Evaluation	Elo tournament (built-in)	No built-in evaluation	Elo ranking (custom implementation)
Philosophy	Human-in-the-loop, dialectical	Autonomous, deterministic	Generate-Debate-Evolve, research-driven
Verification	Red Team auditor (steganography, reward hacking)	Adversarial verification pattern	CITATION-VERIFIER subagent
Governance	Congress + chancela + Quinquennial Plans	None (developer responsibility)	Research Director authority

Pattern Mapping Across Ecosystems

Dynamic Workflow Pattern	Co-Fita Phase	Antigravity Role
Classify-and-act	Phase I Ideation (approach selection)	Research Director (hypothesis routing)
Fan-out-and-synthesize	Phase II Execution (parallel approaches)	Multiple hypothesis subagents
Adversarial verification	Phase III Red Team Audit	CITATION-VERIFIER
Generate-and-filter	Elo Consolidator (tournament)	ELO-RANKER (bracket ranking)
Tournament	Elo Consolidator (pairwise debate)	Elo tournament across sessions
Loop-until-done	Orchestrator `start_loop()`	Generate-Debate-Evolve cycle

The Elo Gap

Antigravity's most distinctive feature was Elo-based evaluation of hypotheses -- a quantitative ranking system that allowed the Research Director to compare approaches across sessions. Dynamic Workflows have no built-in equivalent.

To replicate Elo in Dynamic Workflows:

Implement a judge function that takes two agent results and returns a preference
Use the Tournament pattern for pairwise comparison
Track scores in script variables (or in a file via an agent)
Use the ranking to filter/evolve hypotheses in a Loop-until-done

// Pseudocode: Elo math in a Dynamic Workflow
function eloUpdate(ratingA, ratingB, scoreA, K = 32) {
  const expectedA = 1 / (1 + Math.pow(10, (ratingB - ratingA) / 400));
  const newA = ratingA + K * (scoreA - expectedA);
  const newB = ratingB + K * ((1 - scoreA) - (1 - expectedA));
  return { newA, newB };
}

Co-Fita already implements this in consolidator.py (301 lines, K-factor 32, promotion threshold 1200). The portability is high -- the Elo math is simple arithmetic, and Math is available in the Dynamic Workflows runtime.

Integration Path for Co-Fita

The Optimal Hybrid

Co-Fita's strength is the human-in-the-loop at phase boundaries. Dynamic Workflows' strength is scale and determinism within a phase. The hybrid model:

graph TB
    subgraph "Phase 1: Planning"
        P1[Single Agent<br/>Standard subagent]
    end

    subgraph "Phase 2: Research"
        W2[Workflow: Fan-out-and-Synthesize]
        W2A[Research Agent 1]
        W2B[Research Agent 2]
        W2C[Research Agent N]
        W2 --> W2A
        W2 --> W2B
        W2 --> W2C
    end

    subgraph "Phase 3: Implementation"
        W3[Workflow: Fan-out + Loop-Until-Done]
    end

    subgraph "Phase 4: Review"
        W4[Workflow: Adversarial Verification]
    end

    subgraph "Phase 5: Documentation"
        P5[Single Agent<br/>Wiki-maintainer skill]
    end

    P1 -->|"Human chancela"| W2
    W2 -->|"Human chancela"| W3
    W3 -->|"Human chancela"| W4
    W4 -->|"Human chancela"| P5

Phase-by-Phase Mapping

Co-Fita Phase	Workflow Type	Why
Phase 1: Planning	Single agent	Strategic; does not benefit from fan-out
Phase 2: Research	Fan-out-and-synthesize	Multiple sources in parallel, each with clean context
Phase 3: Build	Fan-out per module + loop-until-tests-pass	Each file gets its own agent; iterate until green
Phase 4: Review	Adversarial verification per artifact	Eliminates self-preferential bias; separate verifier contexts
Phase 5: Docs	Single agent	Deterministic wiki-maintainer; `uv run` scripts

Preserving the Chancela

The critical design constraint: Alefita reviews between phases. Dynamic Workflows do not support mid-run user input, so each phase must be a separate workflow invocation. The chancela happens in the gap between workflow completions:

Workflow 1 (Planning) completes
  -> Alefita reviews plan, gives chancela
    -> Workflow 2 (Research) starts
      -> Alefita reviews findings, gives chancela
        -> Workflow 3 (Build) starts
          -> ...

This preserves the co-fita-governance chancela pattern while gaining Dynamic Workflows' scale advantages within each phase.

What Replaces What

Co-Fita Component	Dynamic Workflow Replacement	What Changes
SearXNG + Crawl4AI in Phase I	Fan-out agents with WebFetch tool	Search becomes agent-level, not harness-level
`acp_client.execute_prompt()`	`agent()` primitive	Model routing moves from Python to JS
`RedTeamAuditor` (Python)	Adversarial verification agent	Verifier gets its own context window
`HashMathVerifier`	Script-level hash computation	JS `crypto` or simplified chain
`FailureTree`	Script variable + agent memory	No persistent tree; need file-based agents
`EloConsolidator`	Tournament pattern + JS Elo math	Must implement Elo in script
Watchdog stall detection	Not needed (JS runtime manages lifecycle)	Watchdog becomes runtime-level
Governance integration	Separate workflow per Congress cycle	Congress as its own workflow

Saving Workflows for Reuse

Workflows can be saved as .js files in:

.claude/workflows/ (project-scoped, git-shared)
~/.claude/workflows/ (personal, cross-project)

Saved workflows accept input through the args global and become available as /commands. This replaces Co-Fita's implicit orchestration in CLAUDE.md with explicit, reusable scripts.

What This Means for the Ecosystem

For Wikifita

Dynamic Workflows can automate wikifita maintenance tasks:

OKF compliance audit: Fan-out per file + adversarial verification against OKF spec
Index reconciliation: Loop-until-done comparing index.md against actual pages
Link validation: Fan-out across all wiki links and media URLs, synthesize broken-link report
Memory consolidation: Classify-and-act routing new memories to correct memorias/ locations

For the ClickFix Study

The clickfix-incident-response monitoring protocol (18h cycles) maps to a Loop-until-done workflow:

Fan out IOC checks across DNS, WHOIS, blockchain, TLS endpoints
Adversarially verify findings against historical baselines
Loop until monitoring cycle completes
Synthesize delta report

For the Unit-Distance Research

The unit-distance-methodology Generate-Debate-Evolve loop maps to Dynamic Workflows' pattern composition. The specific gaps (Elo ranking, channel protocol) can be implemented in JavaScript. Migration path:

Generate = Fan-out-and-synthesize across hypotheses
Debate = Tournament pattern with pairwise judging
Evolve = Loop-until-done with quality convergence
Citation verification = Adversarial verification subagent
Wiki maintenance = Skill script (already uv run)

For Kaggle Agent Security

The kaggle-agent-security attack primitives research informs Dynamic Workflows security:

Identity steering -- each subagent should receive a focused, isolated prompt without ambient identity cues
Decision-collapsing -- structured output schemas (schema option) prevent the agent from silently omitting requirements
Urgency vectors -- workflow scripts encode the objective deterministically, removing context-pressure triggers
Steganography in CoT -- adversarial verification agents can inspect intermediate outputs with their own clean context

Design Constraints

No mid-run user input -- chancela happens between workflow invocations, not within them
No built-in evaluation -- Elo math must be implemented in JavaScript within the script
No channel protocol -- agent reasoning is opaque; only structured output is visible
Coarse resumability -- completed agents are cached; running agents are not checkpointed
Script fragility -- a bug in the generated JS produces undefined behavior; no state machine validator
Token cost -- ultracode significantly increases token usage; model routing to cheaper models for non-critical stages is available

Open Questions

Nested workflow invocation -- Can a workflow call another saved workflow (e.g., /deep-research from within a custom workflow)? Not documented.
Cross-session state -- Agent-memory may bridge the gap, but this is not explicitly addressed.
Maximum script complexity -- Beyond 16-concurrent / 1000-total caps, no documented limits.
Error handling -- How the runtime handles JS errors, agent failures, and timeouts is not detailed.
pipeline() concurrency -- Whether items run sequentially or concurrently (up to 16-agent limit) is implied concurrent but not stated.

This document is alive. It evolves as the research evolves. Challenge it. Improve it. That is the protocol.