Video summary

Claude Code Dynamic Workflows Clearly Explained

Main summary

Key takeaways

Technology

What the video demonstrates (Dynamic Workflows in Claude Code)

The speaker runs a Claude Code “dynamic workflow” that audits/rates 41 skills.

How the workflow runs

  • It spawns 41 “Haiku scoring agents” in parallel (one per skill).
  • It feeds all results into an “Opus synthesis” agent to produce a final ranked view.

Cost/effort observations

  • The parallel fan-out caused very high input token usage (about ~5 million input tokens).
  • Output was relatively small, so it was “not super expensive”, but it’s still easy to burn through a subscription/tokens if careless.
  • A separate test: one workflow prompt consumed about half of a $200/month plan and took 30+ minutes, mainly due to crawling/analyzing many local files/repos.

Output artifact

  • Produces an HTML file ranking skills worst → best.
  • Includes actionable feedback and patterns/warnings for improving skills.
  • The workflow can also merge worker outputs into the final deliverable.

Core concept: Dynamic workflows vs related features

The speaker breaks down a “ladder” of similar-looking constructs and explains differences mainly by:

  • How many agents run
  • Whether agents can communicate
  • Whether there is an iterative loop

1) Skills

  • A reusable recipe (modular capability).
  • Can be used directly with Claude and invoked from automation or other agent structures.
  • “Skill” = reusable procedure, not the orchestration mechanism.

2) Sub-agents

  • Parallel agents spawned to do tasks.
  • Generally do not talk to each other (no shared “council” context).
  • They report results back to the main session.

3) Agent teams

  • Like a small crew where agents do talk to each other.
  • Supports coordination patterns such as debates, war rooms, councils.
  • Typically more expensive due to internal communication and task coordination overhead.

4) Dynamic workflows (new feature)

  • Claude Code generates a JavaScript script that orchestrates execution.
  • Can involve many agents (potentially hundreds).
  • Agents “work alone,” and results get merged at the end.
  • More about width/parallel execution than iterative acceptance criteria.

Plan/implementation detail (important for understanding behavior)

  • With sub-agents/agent teams, the plan is typically “in Claude” during the conversation.
  • With workflows, Claude creates a JS file that then executes the orchestration logic.
  • Workflows are saved and can be re-run later.

Hidden/operational gotchas and workflow management

  • Explicit confirmation: running workflows may require a prompt asking to confirm first.
  • Workflow storage location:
    • By default, scripts may land in a more global Claude Code working directory.
    • To keep them project-local, the speaker saves them under something like:
      • .claude/workflows
  • Monitoring:
    • Using commands like /workflows, you can view active workflows and see:
      • all parallel agents
      • token usage
      • tools used
      • runtime
  • Invocation nuance:
    • Mentioning “workflow” in general chat doesn’t always trigger workflow execution.
    • Best practice: use explicit phrasing like “set me up a dynamic workflow…”.

“Goal” vs “Workflow” (depth/loop vs width/parallel)

  • /goal
    • Acts like a loop until done == true.
    • Can run a long time if the stopping condition isn’t properly bounded.
  • Dynamic workflow
    • Acts more like width/parallel execution.
    • Agents execute predefined tasks and then results are synthesized—no endless done == true loop.
  • Caution: combining them (e.g., a workflow inside a goal) can create very high autonomy and high token-burn risk.

Built-in feature: “Slash deep research”

The speaker calls out a workflow-backed function: /deep research.

  • Spawns parallel agents to research.
  • Agents vote on claims.
  • Produces a cited deep research report at the end.

Recommendation: test it for research-heavy work / building deep research skills, but maintain the same cost-awareness.

When to use which (practical decision guide)

The speaker’s preference:

  • For most knowledge work/automation, workflows may be overkill.

Rule of thumb

  • Use workflows when the job can break into many independent parts that can run concurrently, for example:
    • reviewing every file in a codebase
    • large PR sweeps
    • high-risk migrations (many pieces need parallel reasoning)
  • Avoid workflows for:
    • quick questions
    • single edits
    • general knowledge work
    • tasks that don’t need broad parallelism

Key test

  • “Does this break into many pieces that can run at the same time?”
    • Yes → workflow
    • No → simpler constructs (skills/sub-agents)

Prompt example provided (how the workflow was requested)

The speaker shows a prompt structure that includes:

  • Run a workflow to audit skills from:
    • global/user-level skills
    • project-specific skills
  • Grade criteria: clarity, front matter pass/fail, trigger quality
  • Ask for a single highest value fix
  • Include a final agent to rank skills worst→best

Execution behavior:

  • Worker agents were forced to use Haiku for scoring efficiency.
  • The final synthesis used Opus.

UI/model “ultra code” warning

  • Mentions /effort levels and specifically “ultra code.”
  • Claim: Ultra uses X-high reasoning + workflows by default, making it smartest but most expensive.
  • It also implies it may bypass permissions and immediately orchestrate, increasing cost risk.

Sponsor mention (related to dev tooling)

  • Sponsor: Lovable (website/app builder)
  • Claimed benefits:
    • natural-language builds
    • avoids API key/env handling
    • one-click publish
    • analytics
    • MCP server for connecting multiple tools

Main speakers/sources

  • Primary speaker: the YouTube video narrator/author (unnamed in subtitles)
  • Primary system referenced: Claude Code
    • Claude Opus 4.8 and Haiku agents
    • Commands/functions: /goal, /deep research, /workflows, /effort / “ultra code”

Original video