Claude Code Dynamic Workflows, Ultracode & Subagents Explained (2026)

Claude Code's dynamic workflows let Claude write a JavaScript orchestration script on the fly, fan one task out to many subagents running in parallel (up to 1,000 agents per run, 16 at a time), check their work, and hand you back a single coordinated answer — with intermediate results living in script variables instead of flooding your chat. Ultracode is the companion setting: it pins reasoning effort to xhigh and lets Claude decide for itself when a task is big enough to warrant launching a workflow. Both are in research preview (they need Claude Code v2.1.154 or later), and both sit on top of the older, simpler subagent primitive.

This guide untangles the four ways Claude Code can do work in parallel — subagents, background agents, agent teams, and dynamic workflows — so you know which one to reach for, and what each costs. The features described here are current as of June 2026; because they are evolving research previews, check Anthropic's official docs for the exact behaviour on your version and plan.

What is a dynamic workflow?

A dynamic workflow is, literally, a JavaScript script that Claude writes for your task. When you ask for one, Claude doesn't work through the problem turn by turn — it writes an orchestration script that breaks the work into stages, spawns subagents for each stage, runs them in parallel, and folds the verified results together. A runtime then executes that script in the background while your session stays responsive.

The crucial design choice is where the plan and the intermediate results live. With ordinary subagents, Claude is the orchestrator: it decides turn by turn what to spawn next, and every result lands in Claude's context window. In a workflow, the script holds the loop, the branching, and the intermediate results itself — so Claude's context holds only the final answer, not the hundreds of search results and logs that produced it. That is what makes a fan-out to hundreds of agents practical without blowing the context window.

The hard limits

The runtime enforces concrete caps, which double as cost guardrails:

• 1,000 agents total per run — prevents a runaway loop from spawning forever.
• Up to 16 concurrent agents (fewer on machines with limited CPU cores) — bounds local resource use.
• No mid-run user input — only an agent's permission prompt can pause a run. For sign-off between stages, run each stage as its own workflow.
• No direct filesystem or shell access from the script itself — the agents read, write, and run commands; the script only coordinates them.

Progress is tracked as the run goes, so a run is resumable within the same session: agents that already finished return cached results, and the rest run live. (Exit Claude Code mid-run, though, and the next session starts the workflow fresh.)

Self-verification, not just more agents

Moving the plan into code lets a workflow apply a repeatable quality pattern, not merely run more workers. A workflow can have independent agents adversarially review each other's findings before anything is reported, or draft a plan from several angles and weigh them against each other. The bundled /deep-research workflow is the clearest example: it fans web searches across several angles, fetches and cross-checks the sources, votes on each claim, and returns a cited report with the claims that didn't survive cross-checking already filtered out.

You can have Claude write a workflow for your own task, watch it run in /workflows, and — once a run does what you wanted — press s to save the script as a /command for reuse on every branch or PR.

Ultracode: let Claude decide when to fan out

You have two ways to launch a workflow.

Ask for one in a single prompt. Include the keyword ultracode (or just say "use a workflow") and Claude writes a workflow for that one task:

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Naming note: before v2.1.160 the literal trigger keyword was workflow; it was renamed to ultracode. Natural-language requests ("run a workflow") work in both versions.

Turn it on for the whole session. Ultracode is also a setting that combines xhigh reasoning effort with automatic workflow orchestration:

/effort ultracode

With ultracode on, Claude plans a workflow for each substantive task instead of waiting for you to ask — a single request can become several workflows in a row (one to understand the code, one to make the change, one to verify it). It lasts for the current session and resets when you start a new one; drop back to /effort high for routine work. Because it both raises effort and fans work out, every task uses more tokens and takes longer — which is exactly the tradeoff Indian teams watching API spend need to weigh (more on cost below). Ultracode only appears for models that support xhigh effort.

Subagents: the worker primitive

Underneath workflows is the humble subagent — a specialised worker Claude spawns to handle a side task in its own context window and return only a summary. Use one when a side task would flood your main conversation with search results, logs, or file contents you won't reference again.

The three built-in subagents

| Subagent | Model | Tools | Use it for | | :-- | :-- | :-- | :-- | | Explore | Haiku (fast, cheap) | Read-only (no Write/Edit) | File discovery, code search, understanding a codebase without changing it | | Plan | Inherits main model | Read-only (no Write/Edit) | Gathering context during plan mode before proposing an approach | | general-purpose | Inherits main model | All tools | Complex, multi-step work needing both exploration and code changes |

Explore and Plan deliberately skip your CLAUDE.md and git status to keep research fast and cheap; every other subagent loads both. And critically, subagents cannot spawn other subagents — that prevents infinite nesting. If you need deeper delegation, chain subagents from the main conversation or move up to a workflow.

Why "only a summary" is the whole point

When a subagent finishes, only its summary returns to your main conversation — the verbose searching, reading, and tool output stayed in the subagent's separate context window. This is the entire reason subagents exist: they preserve your context. (The flip side: running many subagents that each return detailed results can still consume significant context, so ask for terse summaries.)

Custom subagents in .claude/agents

When you keep spawning the same kind of worker, define a custom subagent as a Markdown file with YAML frontmatter in .claude/agents/ (project scope, checked into version control) or ~/.claude/agents/ (personal, all projects):

---
name: code-reviewer
description: Reviews code for quality and best practices. Use proactively after changes.
tools: Read, Glob, Grep, Bash
model: haiku
---

You are a senior code reviewer. Focus on quality, security, and best practices.
Report findings as Critical / Warning / Suggestion with concrete fixes.

The body becomes the subagent's system prompt; tools scopes which tools it may use; and model lets you route the worker to a cheaper, faster model like Haiku. For an enterprise team, this is how you bake your own review standards, security checks, or migration playbooks into a reusable, version-controlled worker that everyone on the repo shares.

Subagents vs background agents vs agent teams

This is where most people get confused. Three separate features parallelise work in three different ways. Here is the clean distinction:

| | Subagents | Background agents (agent view) | Agent teams | | :-- | :-- | :-- | :-- | | What it is | A worker inside one session | Independent full sessions run in the background | Multiple coordinated sessions with a lead | | You open it with | Automatic, /agents, or @mention | claude agents | Natural language ("create an agent team") | | Who coordinates | Claude, turn by turn | You — hand off and check back | A lead agent that assigns tasks | | Communication | Report back to the caller only | Report only to you | Teammates message each other via SendMessage | | Status | /agents Running tab | claude agents / claude agents --json | Shared task list |

Background agents (agent view) are full Claude Code sessions that keep running without a terminal attached. You dispatch a bug fix, a PR review, and a flaky-test investigation as three rows, work elsewhere, and step in only when a row needs you. From your shell, claude agents --json prints each live session as a JSON array — entries carry pid, cwd, kind, startedAt, and (when set) sessionId, name, and status. When a session's status is waiting, a waitingFor field tells you what it is blocked on, such as permission prompt or input needed — perfect for scripting an ops dashboard.

Agent teams go further: several full sessions, a lead that assigns work, a shared task list, and direct teammate-to-teammate messaging through the SendMessage tool. They are experimental and disabled by default (enable with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) and shine for adversarial debugging — five teammates each chasing a different hypothesis and trying to disprove each other.

The 2026-06-06 security hardening

If your team runs agent teams, note the change in v2.1.166 (June 6, 2026): Claude Code hardened cross-session messaging so that messages relayed via SendMessage from other Claude sessions no longer carry user authority. Receivers refuse relayed permission requests, and auto mode blocks them. This closes a privilege-escalation path where one session could relay a permission request and have it auto-approved with the recipient's authority — an important guardrail for any IT team enabling multi-agent orchestration in a shared environment.

The /goal command: keep working until done

A related autonomy feature is /goal (added in v2.1.139, May 11, 2026). It sets a completion condition and Claude keeps working across turns until the condition is met — after each turn, a fast model checks whether the goal holds, and if not, Claude starts another turn instead of returning control to you. It works in interactive mode, -p headless mode, and Remote Control, and shows live elapsed time, turns, and token usage in an overlay. The goal clears automatically when met, or you run /goal clear. Pair /goal with a workflow when you want both "keep going until X is true" and "fan the work out."

When should an enterprise or India-based team reach for a workflow?

For most teams in India — where API token spend and latency are real budget lines, and where many shops are doing large legacy migrations (think a decade-old Java or PHP monolith, or a Cobol-to-Java rewrite for a bank or PSU) — the decision tree is straightforward:

Use a single agent or a few subagents when:

• The change is targeted and needs iterative back-and-forth.
• Multiple phases share context (planning → implementing → testing).
• Latency matters and you want to watch each step.

Reach for a dynamic workflow when:

• The work is genuinely parallel and large: a codebase-wide bug sweep, a 500-file migration, a repo-wide refactor, or research that must be cross-checked.
• You want the orchestration codified as a script you can read, audit, rerun on every release, and check into the repo — valuable for regulated sectors (BFSI, fintech, healthtech) that need a reproducible, reviewable process.
• You want adversarial verification built in, not a single best-effort pass.

The cost and latency tradeoff is the catch. A workflow can use meaningfully more tokens than the same task in conversation, and every agent uses your session's model unless the script routes a stage to a cheaper one. Practical discipline for an Indian IT team on a fixed Max/Team/Enterprise budget:

1. Scope before you commit. Run the workflow on one directory or a narrow question first; /workflows shows each agent's token usage live, and you can stop without losing completed work.
2. Route cheap stages to cheap models. Ask Claude to use Haiku for the bulk exploration stages and reserve the strongest model for synthesis — the same per-subagent model lever, applied at scale.
3. Pre-approve allowlists. Workflow subagents run in acceptEdits mode and inherit your tool allowlist; add the shell commands and MCP tools they'll need before a long run so it doesn't stall on a mid-run prompt.
4. Pin down availability and policy. Dynamic workflows are research-preview and admin-gated on Enterprise. Confirm your org has them enabled (/config), and use managed settings ("disableWorkflows": true) if a team needs them off.

Used with that discipline, a fan-out workflow turns an overnight migration that would have taken a developer days of supervised single-agent work into a scripted, verifiable run — while subagents and background agents handle the everyday parallel chores in between. Start small, measure the token spend on a slice, and scale only when the parallelism genuinely pays for itself.

Key takeaways

• Dynamic workflows = Claude-written JS scripts that fan out to up to 1,000 subagents (16 concurrent), self-verify, and keep state in script variables not your context. Research preview, v2.1.154+.
• Ultracode = xhigh effort + Claude auto-deciding when to launch a workflow. Keyword renamed from workflow → ultracode (pre-v2.1.160).
• Subagents (Explore/Plan/general-purpose, plus custom ones in .claude/agents) return only a summary to keep your context clean.
• Background agents (claude agents, --json with waitingFor) you hand off and check back; agent teams (SendMessage, experimental) coordinate and message each other — hardened on 2026-06-06 so relayed messages no longer carry user authority.
• /goal keeps Claude working until a completion condition is met.
• For Indian and enterprise teams: single agent for targeted work, workflow for large parallel jobs — and always scope a slice first to control token cost and latency.