Delegation

Skill

Parallelize work via six patterns: built-in agents (Algorithm/Explore/Plan/general-purpose via Task), worktree-isolated agents (conflict-free parallel edits), background agents (run_in_background, non-blocking), custom agents (ComposeAgent → Task), agent teams (TeamCreate + TaskCreate + SendMessage for multi-turn coordination), parallel task dispatch. Two-tier: lightweight (haiku, max_turns=3, one-shot) vs full (multi-step). Decision rule: agents need to talk or share state → Teams; independent one-shot → Subagents. Auto-invoked by Algorithm at 3+ workstreams. USE WHEN parallel execution, agent team, swarm, spawn agents, fan out, divide and conquer, multi-agent, coordinate agents. NOT FOR single-agent personality composition (use Agents).

Files1
  • @skills/delegation/SKILL.md

Delegation — Agent Orchestration & Parallelization

What It Does

Parallelizes work across six patterns: built-in agents, worktree-isolated agents, background agents, custom agents via ComposeAgent, agent teams via TeamCreate, and parallel task dispatch. It also splits delegation into two weights — lightweight one-shot workers (haiku, capped turns) versus full agents that iterate with tools. The Algorithm auto-invokes it once work hits three or more independent workstreams.

The Problem

Doing independent work serially wastes time, but throwing every task at a heavyweight agent wastes more — spawning a full agent for a one-shot classification burns 10-30 seconds of startup for nothing. Worse, people conflate two different systems: fire-and-forget custom agents with no shared state, and persistent agent teams that message each other and share a task list. Pick the wrong one and you either over-coordinate simple work or under-coordinate complex work. This skill routes each job to the right pattern and the right weight.

How It Works

Auto-invoked by the Algorithm when work can be parallelized or requires agent specialization.

🚨 CRITICAL ROUTING — Two COMPLETELY Different Systems

the user SaysSystemToolWhat Happens
"custom agents", "specialized agents", "spin up agents", "launch agents"Agents Skill (ComposeAgent)Task(subagent_type="general-purpose", prompt=<ComposeAgent output>)Unique personalities, voices, colors via trait composition
"create an agent team", "agent team", "swarm"Claude Code TeamsTeamCreateTaskCreateSendMessagePersistent team with shared task list, message coordination, multi-turn collaboration
These are NOT the same thing:
  • Custom agents = one-shot parallel workers with unique identities, launched via Task(), no shared state
  • Agent teams = persistent coordinated teams with shared task lists, messaging, and multi-turn collaboration via TeamCreate

When the Algorithm Should Use This Skill

  • 3+ independent workstreams exist at Extended+ effort level
  • Multiple identical non-serial tasks need parallel execution
  • Specialized expertise needed (architecture design, implementation, ISC optimization)
  • Large codebase changes spanning 5+ files benefit from parallel workers
  • Research + execution can proceed simultaneously
  • "Create an agent team" — use TeamCreate for persistent coordinated teams
  • Unattended autonomous work where auditability matters more than speed — spawn an Observer team (Agents skill → SPAWNOBSERVERS) alongside the primary agent, reading the tool-activity audit log, voting continue/halt/escalate. ONLY use when BOTH (a) time is not a constraint and (b) auditability is the primary requirement. Never for interactive or time-sensitive work. See Agents/SKILL.md "Observer Team Archetype" for shape and guardrails.

Delegation Patterns

1. Built-In Agents

⚠️ Built-in agents are for internal workflow routing ONLY. When the user asks for custom, specialized, or uniquely-voiced agents, use the Agents skill (section 4 below) instead.
Use Task(subagent_type="AgentType") with these specialized agents:
Agent TypeSpecializationWhen to Use
general-purpose (+ role brief)Code, architecture, design workAdd a senior-engineer/TDD or system-design brief in the prompt — the Engineer/Architect types were retired
AlgorithmISC optimization, criteria workISC-specialized verification
ExploreFast codebase searchQuick file/pattern discovery
PlanImplementation strategyDesign before execution
Always include: Full context, effort budget, expected output format.

2. Worktree-Isolated Agents

Run agents in their own git worktree with isolation: "worktree" for file-safe parallelism:
Task(subagent_type="general-purpose", isolation: "worktree", prompt="Senior engineer, TDD. ...")
  • Each agent gets its own working tree — no file conflicts with other agents
  • Worktree auto-created on spawn, auto-cleaned when agent finishes (unless changes made)
  • Use when multiple agents edit the same files or for competing approaches
  • Can combine with run_in_background: true for non-blocking isolated work
  • Built-in agents with isolation: worktree in frontmatter auto-isolate on every spawn

3. Background Agents

Run agents with run_in_background: true for non-blocking parallel work:
Task(subagent_type="general-purpose", run_in_background: true, prompt="Senior engineer, TDD. ...")
  • Use when results aren't needed immediately
  • Check output with Read tool on the output_file path
  • Ideal for: research, long builds, parallel investigations

3b. Foreground Agents (the default — contrast to pattern 3, not a seventh pattern)

Standard Task() calls that block until complete:
  • Use when you need the result before proceeding
  • Use for sequential dependencies
  • Default mode — most common

4. Custom Agents (via Agents Skill)

Trigger: "custom agents", "spin up agents", "launch agents", "specialized agents" Action: Invoke the Agents skill → run ComposeAgent.ts → launch with Task(subagent_type="general-purpose")
bash
# Step 1: Compose agent identity
bun run ~/.claude/skills/Agents/Tools/ComposeAgent.ts --traits "security,skeptical,thorough" --task "Review auth" --output json

# Step 2: Launch with composed prompt
Task(subagent_type="general-purpose", prompt=<ComposeAgent JSON .prompt field>)
  • Each agent gets unique personality, voice, and color via ComposeAgent
  • Use DIFFERENT trait combinations for each agent to get unique voices
  • Never use built-in agent types for custom work — compose via the Agents skill
  • Ideal for: domain experts, adversarial reviewers, creative brainstormers, parallel analysis

5. Agent Teams (via TeamCreate)

Trigger: "create an agent team", "agent team", "swarm", "team of agents" Action: Use TeamCreate tool → TaskCreate → spawn teammates via Task(team_name=...) → coordinate via SendMessage
text
1. TeamCreate(team_name="my-project")           # Creates team + task list
2. TaskCreate(subject="Implement auth module")   # Create team tasks
3. Task(subagent_type="general-purpose", team_name="my-project", name="auth-engineer")  # Spawn teammate (senior-engineer/TDD brief in prompt)
4. TaskUpdate(taskId="1", owner="auth-engineer") # Assign task
5. SendMessage(type="message", recipient="auth-engineer", content="...")  # Coordinate
This is a COMPLETELY DIFFERENT system from custom agents:
  • Custom agents (Agents skill) = fire-and-forget parallel workers, no shared state
  • Agent teams (TeamCreate) = persistent coordinated teams with shared task lists, messaging, multi-turn
Team Guidelines:
  • Use for 3+ independently workable criteria at Extended+
  • Large complex coding tasks benefit most
  • Each teammate works independently on assigned tasks via shared task list
  • Parent coordinates via SendMessage, reconciles results
  • Teammates go idle between turns — send messages to wake them

When to Use Teams vs Subagents (Decision Matrix)

FactorSubagents (Task)Agent Teams (TeamCreate)
CommunicationFire-and-forget, no peer messagingPersistent messaging between teammates
ContextFresh context each spawn, limited windowFull context window per teammate, preserved across turns
CoordinationParent collects results, no shared stateShared task list, direct peer DMs, idle/wake cycle
DurationSingle-turn executionMulti-turn, iterative work with course corrections
OverheadLow — spawn and forgetHigher — team setup, task creation, message routing
Best forParallel research, one-shot analysis, simple delegationComplex multi-file changes, iterative debugging, cross-layer coordination
Decision rule: If agents need to talk to each other or iterate on shared work → Teams. If each agent does independent one-shot work → Subagents.
Concrete examples:
  • "Research 4 topics in parallel" → Subagents (independent, no coordination needed)
  • "Build a feature spanning API + UI + tests with shared state" → Teams (cross-layer, needs coordination)
  • "Run 10 file updates with same pattern" → Subagents (parallel, identical, independent)
  • "Debug a complex issue with competing hypotheses" → Teams (need to share findings, adjust approach)

6. Parallel Task Dispatch

For N identical operations (e.g., updating 10 files with the same pattern):
  1. Create N Task() calls in a single message (parallel launch)
  2. Each agent gets one unit of work
  3. Results collected when all complete

Effort-Level Scaling

EffortDelegation Strategy
Instant/FastNo delegation — direct tools only
Standard1-2 foreground agents max for discrete subtasks
Extended2-4 agents, background agents for research
Advanced4-8 agents, agent teams for 3+ workstreams
DeepFull team orchestration, parallel workers
ComprehensiveUnbounded — teams + parallel + background

Two-Tier Delegation (Lightweight vs Full)

Not all delegation needs a full agent. Match delegation weight to task complexity:

Lightweight Delegation

For: One-shot extraction, classification, summarization, simple Q&A against provided content.
Task(subagent_type="general-purpose", model="haiku", max_turns=3, prompt="...")
  • Use model="haiku" for cost/speed efficiency
  • Set max_turns=3 — if it can't finish in 3 turns, it needs full delegation
  • Provide all input inline in the prompt (no tool use expected)
  • Examples: "Classify this text as X/Y/Z", "Extract the 5 key points from this", "Summarize this in 2 sentences"

Full Delegation

For: Multi-step reasoning, tasks requiring tool use (file reads, searches, web), tasks that need their own iteration loop.
Task(subagent_type="general-purpose", prompt="...") # or specialized agent type
  • Default model (sonnet/opus inherited from parent)
  • No max_turns restriction — agent iterates until done
  • Agent uses tools autonomously (Read, Grep, Bash, etc.)
  • Examples: "Research X and produce a report", "Refactor these 5 files", "Debug why test Y fails"

Decision Rule

Ask: "Can this be answered in one LLM call with no tool use?" → Lightweight. Otherwise → Full.
SignalTier
Input fits in prompt, output is extraction/classificationLightweight
Needs to read files, search, or browseFull
Needs iteration or self-correctionFull
Simple transform of provided contentLightweight
Requires domain expertise + researchFull
Why this matters: Spawning a full agent for a one-shot extraction wastes ~10-30s of startup overhead and unnecessary context. Lightweight delegation returns in 2-5s. Over an Extended+ Algorithm run with 10+ delegations, this saves minutes. Inspired by RLM's llm_query() vs rlm_query() two-tier pattern (Zhang/Kraska/Khattab 2025).

Right-Sizing Pre-Gate (PLAN, all tiers)

The tier delegation floors set a minimum fan-out. This gate sets the ceiling and the proof you owe. Run it before any fan-out. It exists because over-delegation is one of the most expensive recurring wastes in the reflection log: teams spawned for single-file rewrites, a writing agent that reported "completed" with zero disk writes (110k tokens spent for nothing), 300-agent waves with no headroom left to verify them. The outside proof is Cloudflare's risk-tiered dispatch — scale the agent count to the size of the job. Don't send the dream team to review a typo fix.
  • (a) Zero-agent check. Is the answer already in working memory, or reachable by Glob+Grep+Read in under 30s, or isolated to a single file? Then 0 agents — do it inline. A subagent isn't free; its setup, context load, and result handling cost more than a direct read.
  • (b) Disk-effect probe on every writing agent. An agent that says it wrote or edited files isn't trusted until you confirm it: the file exists AND the diff is non-empty (Read / git diff / Grep the claimed change). A "completed" report is a claim, not evidence. Rule 1 Live-Probe binds delegates exactly as it binds the primary.
  • (c) Budget reservation above ~8 agents. A fan-out past ~8 concurrent agents must reserve explicit verification budget — you can't spend it all generating and none confirming — and name a non-agent fallback branch in ## Decisions for when the wave comes back unusable. This bounds the 5-level nesting capability: nesting multiplies agent count, so the ceiling is on the whole tree, not just the top layer.
Output at the Delegation Gate: 📐 RIGHT-SIZE: [0-agent inline | N agents, disk-probed | N>8, verify-budget reserved + fallback named].

Anti-Patterns (Don't Do These)

  • Don't delegate what Grep/Glob/Read can do in <2 seconds
  • Don't spawn agents for single-file changes
  • Don't create teams for fewer than 3 independent workstreams
  • Don't send agents work without full context — they start fresh
  • Don't use built-in agent names for custom agents
  • Don't use built-in agent types when user asks for specialized or custom agents — always use ComposeAgent via the Agents skill
  • Don't use full delegation for one-shot extraction/classification — use lightweight tier

Gotchas

  • Delegation uses Claude Code's built-in TeamCreate — NOT the Agents skill's ComposeAgent. These are different systems.
  • 3+ independent workstreams warrant delegation. For 1-2 tasks, direct work is faster than team coordination overhead.
  • Agent teams share a task list. Use TaskCreate/TaskUpdate for coordination, not ad-hoc messages.
  • Teams overkill for single-file tasks. (Mar 2026 reflection: "one agent that can both read code and write JSX is better than three specialists who can't coordinate")
  • Forked subagents inherit the full main-thread conversation + share its prompt cache (Anthropic CC v2.1.133+, enabled via CLAUDE_CODE_FORK_SUBAGENT=1 env or agent frontmatter context: fork). Use forked subagents for nuance-dependent work: design variations, follow-on research, anything that depends on context the main thread already established. DO NOT FORK for code review — a forked reviewer defends its own code (R Amjad: "biased toward defending own code"). For convergence questions, run one fork + one non-fork in parallel and look at where they disagree.

Examples

Example 1: Parallel implementation
text
User: "build the frontend and backend in parallel"
→ Creates team via TeamCreate
→ Spawns frontend and backend agents
→ Shared task list for coordination
→ Agents work independently, merge results
Example 2: Research swarm
text
User: "launch an agent team to research these 5 topics"
→ Creates team with 5 research agents
→ Each agent handles one topic independently
→ Results synthesized by team lead

Execution Log

After completing any workflow, append a single JSONL entry:
bash
echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Delegation","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl
Replace WORKFLOW_USED with the workflow executed, 8_WORD_SUMMARY with a brief input description, and SECONDS with approximate wall-clock time. Log status: "error" if the workflow failed.
Delegation — Kortix Marketplace | Kortix