Master Claude Code’s New Features: /goal, Subagents, Dynamic Workflows, and Agent Teams

Overview of New Claude Code Automation Features

Claude Code adds four automation primitives that extend the developer workflow: /goal (condition‑driven loops), Subagents (isolated assistants), Dynamic Workflows (JavaScript‑based orchestration of many agents), and Agent Teams (experimental multi‑session collaboration).

/goal: Condition‑Driven Automation

Traditional conversational coding requires a prompt for each step, which becomes cumbersome for multi‑step tasks such as full‑module migrations or bulk lint fixes. The /goal command lets the user declare a completion condition; Claude then runs a round, evaluates the condition with a lightweight model (default Haiku ), and repeats until the condition is satisfied.

Basic Usage

/goal auth module tests pass and lint clean

Entering a /goal automatically triggers the first round. A clock icon shows elapsed time. Each round ends with the evaluator model returning a yes/no decision and a brief rationale.

Goal Management Commands

/goal

– view current status (round count, latest evaluation). /goal <new condition> – replace the active goal. /goal --clear – manually clear an unfinished goal.

Starting a new conversation automatically clears any active goal.

Resuming a Goal

If a session ends while a goal is active, /resume restores it. The condition is kept, but counters, timers, and token usage are reset. Completed or cleared goals are not restored.

Writing Effective Goal Conditions

Define a verifiable result (e.g., test suite passes, build exit code 0, file count, empty queue).

Specify how Claude can prove it (e.g., run npm test and confirm all cases pass).

State immutable constraints (e.g., "do not modify other test files").

Conditions may be up to 4000 characters. Turn or time limits can be added to avoid runaway execution, e.g.,

All API endpoints must have authentication checks and finish within 5 rounds

Goal Evaluation Mechanism

/goal

is a wrapper around a session‑level stop hook. After each round the conversation content and the goal condition are sent to the evaluator model, which returns a yes/no decision and a short reason. The evaluator cannot invoke tools, so the condition must be expressible solely from Claude’s own output (e.g., test results that Claude prints).

Comparison with Other Automation Modes

/goal – proceeds to the next round only when the evaluation model reports the condition is not yet met. Ideal for tasks with a clear termination point.

Auto mode – automatically approves each tool call, reducing per‑round confirmation but still requires an explicit stop condition.

Stop hook – custom script or prompt can decide when to stop; useful when bespoke evaluation logic is needed.

Timed task – triggers on a time interval, independent of the session.

These modes can be combined; /goal runs on top of auto mode.

Subagents: Dedicated AI Assistants

Subagents run in independent context windows with their own system prompt, tool permissions, and optional memory. They return only a summary to the parent conversation, preventing the main context from being flooded with auxiliary output.

Built‑In Subagents

Explore – read‑only tools; used for code search, file discovery, repository exploration.

Plan – inherits the main session’s tools; suited for planning‑mode research.

General‑purpose – full read/write access; handles complex research, multi‑step operations, and code modification.

Built‑in agents skip the CLAUDE.md and parent git status, making exploration faster and cheaper token‑wise. The Explore agent accepts a thoroughness level (quick, balanced, thorough).

Creating Custom Subagents

Two methods are supported:

Graphical UI – run /agents, click Create , fill in name (lower‑case, hyphenated) and description, optionally set tools, model, max_turns, memory, etc., then save.

Manual YAML file – place a Markdown file with YAML front‑matter in one of the following scopes:

Project level: .claude/agents/code-reviewer.md (shared via version control).

User level: ~/.claude/agents/code-reviewer.md (available to all personal projects).

Plugin level: my‑plugin/agents/… (distributed with a plugin).

CLI argument: --agent '{"name":"…"}' (one‑off).

Example front‑matter (excerpt):

---
name: code-reviewer
description: 审查代码质量和最佳实践
model: claude-sonnet-4-20250514
tools: [Read, Grep, Glob, Bash]
color: blue
---
你是一个代码审查员。被调用时分析代码并提供具体、可操作的反馈，覆盖代码质量、安全性和最佳实践。指出每个问题、展示当前代码并提供改进版本。

Tool Permission Control

Allowlist mode – only the explicitly listed tools are available, e.g. tools: [Read, Grep, Glob, Bash] Denylist mode – inherit all tools except those listed in denied_tools, e.g.

tools: null  # inherit all
 denied_tools: [Edit, Write]

Some tools are never permitted inside Subagents (Agent tool, AskUserQuestion, interactive Bash commands).

MCP Server Scope

Subagents can access additional MCP servers not present in the main session. Define them inline (available only to that Subagent) or reference an existing server (shared with the main session). Inline servers are connected at Subagent start and disconnected at exit, avoiding extra context usage.

Practical Tips for Subagents

Write a clear description that states when the Subagent should be used; Claude uses this to decide delegation.

Choose an appropriate model: Haiku for simple search, Sonnet for code review, Opus for heavy reasoning.

Be aware that summaries and tool results still flow back to the parent conversation, affecting token consumption.

Remember Subagents inherit the parent’s permission mode; in auto mode they run without confirmation prompts.

Enable memory if you want the Subagent to retain insights across sessions.

Subagent vs. Fork

Forks ( /fork) create a completely independent session with its own history, useful for exploring alternative solutions. Subagents stay within the same session, report back to the parent, and share the parent’s permission configuration. Use forks for divergent experiments; use Subagents for isolated sub‑tasks.

Dynamic Workflows: Scripted Orchestration of Hundreds of Agents

Dynamic Workflows are JavaScript files executed in an isolated environment. They coordinate many Subagents, making them ideal when the required number of agents exceeds what a single conversation can handle or when you want a reusable, version‑controlled automation script.

Typical Use Cases

Scanning an entire codebase (e.g., 500 files) for bugs.

Large‑scale API migrations.

Cross‑validation of research questions.

Generating multiple design proposals for later comparison.

Version requirement: Claude Code v2.1.154 or newer (available on all paid plans).

Getting Started

The built‑in /deep-research command demonstrates a workflow:

/deep-research Node.js permission model changes between v20 and v22?

Claude spawns several agents that search, verify sources, and synthesize a citation‑rich report while keeping the main session responsive.

Workflow Script Structure

A workflow script is a plain JavaScript file that uses the agent() API to launch agents with specific goals, models, and turn limits. Example fragment:

// Create an agent to scan for security issues
const result = await agent({
  goal: "Scan src/auth/ for security vulnerabilities",
  model: "claude-sonnet-4-20250514",
  max_turns: 20
});

// Run several agents in parallel and synthesize results
const results = await Promise.all([
  agent({goal: "Analyze performance bottlenecks"}),
  agent({goal: "Check security risks"}),
  agent({goal: "Assess test coverage"})
]);
return synthesize(results);

Key API calls: agent({goal, model?, max_turns?}) – launches a single Subagent. synthesize(arrayOfResults) – combines the outputs.

Runtime Constraints

Maximum of 16 concurrent agents (fewer on limited GPU/CPU).

Workflows cannot directly access the file system or shell; agents can.

Spawned agents inherit the main session’s model unless overridden.

Agents run in bypass‑permissions mode, automatically approving file edits.

Tool calls not in the allowlist may still trigger confirmation prompts.

Management Commands

Use /workflows to list active and completed workflows, inspect each phase’s agent count, token usage, and duration, and view individual agent prompts and results. In the /workflows view, press s to save a workflow as a reusable command (project‑level or user‑level).

Running and Recovering Workflows

/workflows

shows each workflow’s phases; selecting a phase reveals the agents involved, their prompts, tool calls, and results. Stopping a workflow preserves completed agent results; restarting resumes from the last unfinished phase. Exiting Claude Code clears the in‑memory state, so a full restart begins from the first phase.

Network / Proxy Considerations

If a workflow needs network access, ensure the environment variable CLAUDE_CODE_DISABLE_WORKFLOWS is unset or set to 0. Administrators can globally disable workflows via managed-settings.

Agent Teams: Multi‑Session Collaborative Clusters (Experimental)

Agent Teams coordinate multiple independent Claude Code sessions into a collaborative cluster. A Lead session orchestrates work, while Teammates run in their own contexts and can exchange messages directly, unlike Subagents which only report back.

Enabling

Set the environment variable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 to enable this feature.

When to Use

Code review from multiple perspectives (security, performance, test coverage).

Multi‑angle debugging debates.

Parallel refactoring of front‑end, back‑end, and tests.

Design exploration that combines UX, architecture, and critique.

Task System

Teams share a task list with three states:

Pending – not yet claimed.

In progress – currently being worked on.

Completed – finished.

Tasks may have dependencies; the Lead can assign tasks explicitly or let Teammates claim them.

Interaction Modes

In‑process (default) – Teammates appear in the main terminal and can be switched with Shift+Down.

Split‑pane – each Teammate gets its own pane (requires tmux, iTerm2, etc.).

Best Practices

Keep the team size to 3‑5 Teammates to limit coordination overhead.

Assign each Teammate a distinct file scope to avoid edit conflicts.

Group 2‑3 related tasks per Teammate for steady output.

Give explicit names to Teammates for easier referencing.

Use Plan approval: Teammates propose solutions, Lead approves before execution.

Let the Lead perform cleanup with lead clean up.

Known Limitations

Requires a stable terminal environment, especially for split‑pane mode.

All Teammates share the same permission mode; per‑Teammate permissions are not supported.

Teammates may not auto‑recover from errors.

Large teams consume significant system resources.

Choosing Between /goal, Subagents, Workflows, and Agent Teams

If you need Claude to iterate until a specific condition is met – use /goal.

If you have a clear sub‑task that returns a result – use a Subagent.

If you need dozens to hundreds of agents in parallel or a reusable script – use Dynamic Workflows.

If multiple agents must communicate, challenge each other, and collaborate – use Agent Teams.

For a background sub‑task while you continue coding – use a backend Subagent.

For scheduled recurring jobs without user presence – combine a timed task with a Workflow.

Suggested Progression

Start with /goal for most multi‑step tasks.

If a distinct sub‑task emerges, create a Subagent with a clear description.

For batch operations that must be repeatable, write a Dynamic Workflow and save it.

When agents need to interact or debate, enable Agent Teams (mind token usage).