cubetribe/claudecode_godmode-on/dynamic-workflows

Dynamic Workflows (Ultracode / Max-Parallel Mode)

Status: Production-ready opt-in. Requires Claude Code v2.1.154+.

When to use: A job outgrows a handful of subagents and needs adversarial cross-checks — codebase-wide audits, large migrations, or multi-angle research where correctness matters more than cost.

What Is a Dynamic Workflow?

A dynamic workflow is a Claude-written script that fans work out across tens to hundreds of parallel subagents, runs adversarial verification (agents try to refute each other's findings), iterates until answers converge, and returns only the verified result.

Key properties:

• Claude-authored: The orchestrator generates the workflow script for the specific job — it is not a static template.
• Fan-out/fan-in: Work is decomposed into independent units and dispatched in parallel. Results are collected, cross-checked, and synthesized.
• Adversarial verification: For each finding, a separate set of "skeptic" subagents attempts to refute it. A finding survives only if a majority of skeptics cannot disprove it.
• Perspective-diverse verifiers: Skeptics receive different framings, file subsets, or role priming so they do not share the same blind spots as the primary agents.
• Iterative convergence: Rounds repeat until findings stabilize — contested results are re-examined rather than silently dropped.
• Returns only the verified result: The final output is the convergence-confirmed set of findings, not raw subagent output.

Trigger: the word "workflow" in a prompt, or automatically when the ultracode switch is on. Inspect running and past workflow runs with /workflows.

When to Use Which Surface

Four parallelization surfaces exist in CC_GodMode. Choose based on job size and verification need:

Decision shorthand:

• One-off side task with a few parallel steps → subagents (single message, fan-out in-session).
• Large feature with persistent, synchronized teammates → agent teams.
• Job outgrows ~10 concurrent workers OR correctness requires adversarial verification → dynamic workflows.

Supporting tools that work with all surfaces:

• Worktrees — separate git checkout per parallel session, avoids file conflicts.
• `/batch` — splits one large change into 5–30 worktree-isolated subagents that each open a PR.
• Forked subagent — inherits full conversation context when continuity matters.

How to Trigger Dynamic Workflows

Via prompt word (any session):

Include the word workflow in your request:

workflow: audit every API route in src/api/ for missing auth checks

Via ultracode (recommended for large or time-critical jobs):

/model opus
/effort ultracode

ultracode is a separate, session-only switch (/effort ultracode, or /effort ultracode on|off) — it is not an effort level and leaves the effort setting unchanged (valid levels: low | medium | high | xhigh | max; Opus 5.5 and Sonnet 5.5 default to medium). While on, Claude automatically orchestrates dynamic workflows for substantive tasks. It requires dynamic workflows to be enabled in /config, is available depending on the model, and cannot live in the effortLevel settings field. For a single prompt, include the keyword ultracode instead. /model best (Fable 5.1 where available) is an optional upgrade, not a requirement.

Via settings (persist across sessions):

{
  "model": "opus",
  "ultracode": true
}

Pass ultracode: true via --settings or an Agent SDK control request.

Inspect runs:

/workflows

Lists running and completed workflow runs with status and subagent counts.

Adversarial Verification Pattern

The verification loop is what separates dynamic workflows from naive fan-out:

Round N
  ├── Primary agents (P workers)
  │     each processes an independent unit and returns findings
  │
  └── Skeptic agents (S skeptics per finding)
        each receives a finding + relevant context
        task: find errors, missing cases, or counter-evidence
        verdict: REFUTE | CONFIRM | INCONCLUSIVE
 
Convergence check
  ├── MAJORITY REFUTE → finding killed; if important, re-examine in Round N+1
  ├── MAJORITY CONFIRM → finding promoted to verified set
  └── INCONCLUSIVE → finding queued for another round (up to max_rounds)
 
Final output: verified set only

Perspective diversity: skeptics are given different role priming, different file subsets, or different question framing to avoid correlated failures. If all skeptics share the same blind spot as primary agents, verification is meaningless.

Practical implication: you get fewer findings than a naive scrape, but the ones returned are high-confidence. For security audits or migration correctness checks this tradeoff is usually correct.

Verification Scoping — Facts Only, Not Judgment

Adversarial verification only works on refutable claims: a skeptic must be able to disprove the finding with a concrete counterexample. That is true for factual, checkable findings — it is not true for design/architecture judgment calls, where "refuting" the claim would require generating a better design, which is exactly the capability a same-tier skeptic lacks. Routing a judgment question into a skeptic panel produces confident consensus error, not signal: same-tier judges share the same blind spot as the primary agent and majority-vote the error through instead of catching it.

Litmus test: if refuting the claim requires only checking, running, or grepping something that already exists (fact), it verifies adversarially; if refuting it requires producing a better alternative that doesn't yet exist (judgment), it escalates.

When a finding falls in the right-hand column, do not spin up a skeptic panel — route it per the QUALITY-GATES adjudication procedure's Step 3 (docs/orchestrator/QUALITY-GATES.md): not criteria-resolvable ⇒ mandatory human escalation. A unanimous same-tier PASS on a judgment question is not evidence; it is a correlated miss waiting to happen.

Decomposition Seam-Check

Before dispatching a multi-agent decomposition, the orchestrator writes one line naming the cross-cutting concern the split could hide, e.g.:

seams: auth flow crosses builder-A/builder-B file boundary

This is cheap — one sentence — but closes real recall gaps: cross-cutting bugs live in the seams between subagent scopes, not inside any single unit, so no per-unit gate catches them by default. Where the seam is non-trivial (the concern spans behavior, not just adjacent files), assign one seam-checker agent whose only job is reading ACROSS the completed units' outputs for cross-cutting breakage — it does not re-review any single unit in isolation; that is the primary agent's and the quality gates' job.

Concurrency Caps and Rate-Limit Awareness

Practical guidance:

• For organizations on standard tiers, a workflow dispatching 50+ subagents simultaneously can hit rate limits. The workflow script handles backpressure and retry internally, but very large jobs may need to be staged.
• Token throughput (not just request count) matters: each subagent has its own context. 100 subagents at 50K tokens each = 5M tokens for that round.
• Check your org's rate-limit tier before scheduling large overnight workflow runs.
• Use /workflows to monitor active runs and cancel runaway jobs early.

Worktree Isolation and /batch

When parallel subagents edit overlapping files, race conditions and merge conflicts are likely without isolation.

Worktrees: Each parallel session operates on a separate git checkout of the same repository. Changes are made in isolation and merged afterward. Use when multiple subagents will write to the same files.

# The workflow script manages this automatically under ultracode
# Manual setup for custom scripts:
git worktree add ../branch-A feature/branch-A
git worktree add ../branch-B feature/branch-B

`/batch`: Splits one large change into 5–30 worktree-isolated subagents that each open a pull request. Good for applying a uniform transformation across many files without a full dynamic workflow overhead.

/batch: apply the new error-handling pattern to every file in src/handlers/

When to use each:

Cost Tradeoff — The Guardrail

Parallelism cuts wall-clock time by ~60–80% on independent work. It does not reduce cost.

Running many workers at once multiplies token usage. Dynamic workflows add on top of that: adversarial verification means each finding is examined multiple times by multiple agents. For a large codebase audit this can burn substantially more tokens than a focused single-agent session.

Therefore:

• Smart Routing stays the default (skills/cost-efficiency/). The Orchestrator applies it automatically.
• Dynamic workflows are an explicit, deliberate opt-in — triggered by the word workflow or by the user switching on ultracode.
• Before triggering ultracode on a large job, consider whether Smart Routing with a few targeted subagents would reach the same result at lower cost.
• Use dynamic workflows when correctness at scale matters more than token cost: security audits, migration correctness, large multi-angle research where a missed finding has downstream consequences.

Cost signal by surface (relative):