2. Delegación Paralela — Syntax, Patterns, y Límites

Descripción

La delegación paralela en Claude Code no requiere APIs de concurrencia ni threads — funciona a nivel de subagents. Cuando le pides a Claude que ejecute múltiples tareas independientes, puede lanzar varios subagents simultáneamente: uno investiga el módulo de auth mientras otro analiza el de productos, un tercero revisa la base de datos. Los tres trabajan al mismo tiempo, y Claude consolida los resultados cuando terminan.

La mecánica tiene dos dimensiones: cuándo se ejecuta algo en paralelo (background execution, prompting patterns) y cómo se aíslan los agentes para que no se pisen (git worktrees). Entender ambas es lo que separa "lanzar agentes al mismo tiempo y rezar" de "orquestar delegación paralela con aislamiento."

Al terminar esta cápsula sabrás exactamente cómo activar la ejecución paralela — el campo background: true, el atajo Ctrl+B, los prompts que instruyen a Claude a delegar en paralelo, y el campo isolation: worktree que previene conflictos de escritura. También sabrás cuándo NO usarla, que es igual de importante.

Background Execution: El Mecanismo Base

Cómo funciona

Cuando Claude Code delega a un subagent, normalmente lo hace en foreground — espera a que termine antes de continuar. Con background execution, el subagent se ejecuta en segundo plano mientras Claude (o tú) continúa con otra cosa.

Foreground (default):
Claude → lanza subagent A → espera... → recibe resultado → continúa

Background:
Claude → lanza subagent A en background ─┐
       → lanza subagent B en background ──┤ (simultáneo)
       → lanza subagent C en background ──┘
       → espera que todos terminen → consolida resultados

Tres formas de activar background execution

1. Campo background: true en frontmatter:

---
name: module-researcher
description: Researches a specific module for patterns and issues
tools: Read, Glob, Grep
model: haiku
background: true
---

You are a code researcher. Analyze the specified module and report...

Cuando background: true está en el frontmatter, este subagent siempre se ejecuta en background. Es útil para subagents que por diseño son asíncronos — investigación, análisis, tareas de solo lectura que no bloquean el flujo principal.

2. Ctrl+B para backgroundear una tarea en ejecución:

Si un subagent ya está ejecutándose en foreground y notas que no necesitas esperar, presiona Ctrl+B. Claude mueve la ejecución a background y tú puedes seguir interactuando. Cuando el subagent termina, el resultado aparece en la conversación.

Tú: "Usa el code-reviewer para analizar todo el proyecto"
Claude: [empieza a ejecutar el reviewer]
Tú: [presionas Ctrl+B]
Claude: "He enviado el reviewer a background. ¿En qué más puedo ayudarte?"
[...trabajas en otra cosa...]
Claude: "El reviewer terminó. Aquí están los resultados:"

3. Claude decide automáticamente:

Cuando tu prompt implica múltiples tareas independientes, Claude puede decidir por sí mismo enviar subagents a background. No necesitas pedirlo explícitamente cada vez — pero los prompts explícitos son más predecibles.

Prompting Patterns para Delegación Paralela

Pattern 1: Investigación paralela explícita

El patrón más directo. Le pides a Claude que investigue múltiples áreas simultáneamente:

Investiga los módulos auth, products, y orders en paralelo.
Para cada uno, reporta: estructura de archivos, dependencias externas,
y patrones de error handling.
Usa subagents separados para cada módulo.

Claude lanzará 3 subagents — uno por módulo — y los ejecutará concurrentemente. Cada subagent tiene su propio contexto y solo ve los archivos que le corresponden.

Pattern 2: Delegación implícita por independencia

Cuando describes tareas que Claude reconoce como independientes, puede paralelizar automáticamente:

Necesito que hagas 3 cosas:
1. Actualiza los type hints en src/auth/
2. Agrega docstrings a todas las funciones públicas en src/products/
3. Standardiza el error handling en src/orders/

Estas tareas son independientes entre sí.

La frase clave es "independientes entre sí" — le da a Claude la señal de que puede paralelizar.

Pattern 3: Refactor en paralelo con worktrees

Para tareas que modifican archivos, necesitas aislamiento:

Refactoriza estos 4 módulos en paralelo, cada uno con un subagent
separado en un worktree aislado:
- src/auth/ — actualizar a Pydantic v2 models
- src/products/ — agregar pagination a todos los endpoints
- src/orders/ — implementar soft delete
- src/notifications/ — migrar a async handlers

Al terminar, consolida los cambios de los 4 worktrees.

Pattern 4: Análisis paralelo con merge

Analiza el rendimiento de la API en paralelo:
- Un subagent analiza los endpoints de lectura (GET)
- Otro subagent analiza los endpoints de escritura (POST, PUT, DELETE)
- Un tercero analiza los queries a la base de datos

Cuando los 3 terminen, dame un reporte unificado con las top 5
oportunidades de optimización.

Anti-patterns: lo que NO funciona

❌ "Haz todo más rápido usando paralelismo"
   → Demasiado vago. Claude no sabe qué paralelizar.

❌ "Ejecuta el reviewer y el implementer en paralelo"
   → El implementer NECESITA el resultado del reviewer. Dependencia.

❌ "Lanza 10 subagents, uno por archivo"
   → Overhead excesivo. Cada subagent consume context window.

Isolation con Git Worktrees

El problema que resuelve

Sin aislamiento, dos subagents que editan archivos al mismo tiempo pueden crear conflictos:

Subagent A edita src/models/user.py (agrega campo email)
Subagent B edita src/models/user.py (agrega campo phone)

Sin aislamiento:
→ Uno sobreescribe los cambios del otro
→ O un agente ve un archivo "a medio editar" por el otro

Git worktrees resuelven esto dándole a cada subagent su propia copia aislada del repositorio.

Cómo funciona isolation: worktree

---
name: module-refactorer
description: Refactors a specific module with isolation
tools: Read, Write, Edit, Grep, Glob
isolation: worktree
---

Refactor the specified module following project conventions...

Cuando un subagent tiene isolation: worktree, Claude Code:

1. Crea un git worktree temporal — una copia del repositorio que comparte el historial de git pero tiene su propio working directory
2. El subagent trabaja exclusivamente en ese worktree — sus lecturas y escrituras no afectan al repositorio principal
3. Al terminar, los cambios del worktree se mergean de vuelta al repositorio principal
4. Si el subagent no hizo cambios, el worktree se limpia automáticamente

Repositorio principal:
  /your-project/
  ├── src/auth/
  ├── src/products/
  └── ...

Worktree del subagent A:
  /tmp/worktree-auth-xxxxx/
  ├── src/auth/        ← edita aquí
  ├── src/products/    ← intacto
  └── ...

Worktree del subagent B:
  /tmp/worktree-products-xxxxx/
  ├── src/auth/        ← intacto
  ├── src/products/    ← edita aquí
  └── ...

Cada subagent ve el repositorio completo pero solo modifica su módulo. No hay conflictos de escritura porque cada uno trabaja en su propia copia.

Worktree + background: la combinación para edición paralela

Para subagents que editan archivos en paralelo, combina ambos campos:

---
name: auth-refactorer
description: Refactors the auth module
tools: Read, Write, Edit, Grep, Glob
background: true
isolation: worktree
---

Refactor src/auth/ following these criteria...

background: true → se ejecuta en paralelo con otros subagents isolation: worktree → edita archivos sin conflictos

Cuándo NO necesitas worktrees

Si los subagents paralelos solo leen archivos (no editan), no necesitas aislamiento:

---
name: module-analyzer
description: Analyzes a module (read-only)
tools: Read, Glob, Grep
background: true
---

Múltiples lectores paralelos no generan conflictos. Solo necesitas worktrees cuando hay escritura paralela.

Limpieza automática de worktrees

Si un subagent con isolation: worktree termina sin hacer cambios (solo leyó archivos, o decidió que no había nada que cambiar), el worktree se limpia automáticamente. No quedan directorios temporales huérfanos.

Si el subagent sí hizo cambios, Claude Code se encarga del merge de vuelta al repositorio principal. Si hay conflictos de merge (raro si los subagents editan módulos independientes), Claude te los presenta para resolución.

Permisos en Background Mode

La restricción: sin interacción en background

Un subagent en background no puede pedirte confirmación. No hay un humano esperando para aprobar cada acción. Esto tiene implicaciones para los permisos:

Foreground: "¿Puedo editar src/auth/models.py?" → Tú: "Sí" → Edita

Background: "¿Puedo editar src/auth/models.py?" → ... nadie responde → FALLA

Permisos pre-aprobados

Para que un subagent funcione correctamente en background, Claude Code pre-aprueba los permisos basándose en las herramientas definidas en el frontmatter. Si el subagent tiene tools: Read, Write, Edit en su frontmatter, esas herramientas están pre-aprobadas para uso sin confirmación.

---
name: background-implementer
tools: Read, Write, Edit, Grep, Glob
background: true
---

Este subagent puede leer, escribir, y editar archivos sin pedir confirmación — porque opera en background.

Qué pasa si falla por permisos

Si un subagent en background necesita una herramienta que no tiene pre-aprobada, falla silenciosamente en esa acción. Puedes resumir la tarea en foreground para resolver el problema:

Claude: "El subagent background-implementer no pudo completar la tarea
         porque necesitó ejecutar un comando Bash que no estaba en su
         lista de herramientas."

Tú: "Resúmelo en foreground"

Claude: [re-ejecuta en foreground, te pide confirmación para Bash]

Para evitar esto, asegúrate de que el frontmatter incluya todas las herramientas que el subagent podría necesitar.

permissionMode y background

El campo permissionMode interactúa con background execution:

En background, la distinción entre default y acceptEdits desaparece — ambos pre-aprueban las herramientas del allowlist.

Límites de la Delegación Paralela

Los subagents no pueden lanzar subagents

Un subagent no puede delegar a otro subagent. La jerarquía es de un nivel:

✅ Válido:
Claude (main) → subagent A (en paralelo)
              → subagent B (en paralelo)
              → subagent C (en paralelo)

❌ No válido:
Claude (main) → subagent A → sub-subagent A1
                             → sub-subagent A2

Si necesitas subdivisión de tareas dentro de un subagent, la lógica debe estar en su system prompt, no en delegación anidada.

Consumo de context window

Cada subagent paralelo consume su propia context window. Si lanzas 4 subagents con model: sonnet, estás usando 4 context windows simultáneamente. Esto no es un problema técnico (se ejecutan), pero sí de costo — cada subagent consume tokens independientemente.

1 subagent sonnet con 50K tokens de contexto = X tokens
4 subagents sonnet en paralelo = 4X tokens

Para tareas de solo lectura o análisis simple, usa model: haiku que es más económico.

Límite práctico de paralelismo

No hay un límite técnico estricto de cuántos subagents puedes lanzar en paralelo, pero hay límites prácticos:

• 2-4 subagents paralelos: Óptimo. Buen balance entre velocidad y manejo de resultados
• 5-8 subagents paralelos: Funciona, pero la coordinación de resultados se complica
• 10+ subagents paralelos: Diminishing returns. El overhead de coordinación supera el beneficio de paralelismo

La recomendación: empieza con 2-3 subagents paralelos y escala si necesitas más.

No toda tarea se beneficia

El overhead de crear un subagent (context initialization, tool setup) es constante. Si una tarea tarda 10 segundos de forma secuencial, paralelizarla con un subagent puede tardar más por el overhead de setup.

Tarea de 10s secuencial  →  No paralelizar (overhead > beneficio)
Tarea de 60s secuencial  →  Buen candidato
Tarea de 5min secuencial →  Excelente candidato

Regla: si la tarea individual tarda menos de 30 segundos, probablemente no vale la pena crear un subagent separado para ella.

Sequential vs Parallel: Cuándo Usar Cada Uno

La decisión no es "siempre paralelo"

El test de independencia

Antes de paralelizar, hazte estas preguntas:

1. ¿La tarea B necesita el output de la tarea A? → Si sí, secuencial.
2. ¿Ambas tareas editan el mismo archivo? → Si sí, secuencial (o worktree con merge cuidadoso).
3. ¿El resultado de una tarea invalida asunciones de la otra? → Si sí, secuencial.
4. ¿Cada tarea puede empezar ahora con la información que ya existe? → Si sí, paralelo.

Si las 4 respuestas son "no, no, no, sí" — paraleliza sin dudarlo.

Hybrid: Paralelo con secuencia

El patrón más poderoso combina ambos:

Fase 1 (paralelo):
├── Investigar auth module      ──┐
├── Investigar products module  ──┤ (simultáneo)
└── Investigar orders module    ──┘
              ↓
Fase 2 (secuencial):
└── Coordinar hallazgos y crear plan unificado
              ↓
Fase 3 (paralelo):
├── Implementar cambios en auth      ──┐
├── Implementar cambios en products  ──┤ (simultáneo, worktrees)
└── Implementar cambios en orders    ──┘
              ↓
Fase 4 (secuencial):
└── Merge + testing

Investigación en paralelo → planificación secuencial → implementación en paralelo → verificación secuencial. Cada fase usa el modo que maximiza eficiencia para el tipo de tarea.

Ejemplo Completo: Análisis Paralelo de 3 Módulos

Los subagent files

Crea 3 subagent files para análisis paralelo:

.claude/agents/module-analyzer.md:

---
name: module-analyzer
description: Analyzes a specific module for patterns, issues, and improvement opportunities. Read-only.
tools: Read, Glob, Grep
model: haiku
background: true
maxTurns: 10
---

## Role
You are a module analyzer. When given a module path, analyze it completely.

## Process
1. List all files in the module with Glob
2. Read each file
3. Identify: public API, internal helpers, dependencies, error patterns
4. Report findings in the exact format below

## Output Format

### Module Analysis: [module name]

**Files:** [count]
**Lines of code:** [approximate]
**Dependencies:** [external imports]

#### Public API
- [function/class name] — [what it does]

#### Patterns Found
- [pattern name] — [where and how it's used]

#### Issues
- [issue] — [file:line] — [severity]

#### Improvement Opportunities
- [opportunity] — [estimated effort: low/medium/high]

El prompt de ejecución

Analiza estos 3 módulos en paralelo usando el module-analyzer:
1. src/auth/
2. src/products/
3. src/orders/

Cuando los 3 terminen, dame un reporte comparativo:
- Qué módulo tiene más issues
- Qué patrones son comunes a los 3
- Top 5 mejoras prioritarias considerando los 3 módulos

Lo que sucede internamente

Claude (main):
  1. Lee el prompt
  2. Lanza module-analyzer(src/auth/)     → background
  3. Lanza module-analyzer(src/products/) → background
  4. Lanza module-analyzer(src/orders/)   → background
  5. Espera los 3 resultados
  6. Consolida en reporte comparativo
  7. Te presenta el resultado

Los 3 subagents trabajan simultáneamente. Si src/auth/ toma 30s, src/products/ toma 45s, y src/orders/ toma 35s:

• Secuencial: 30 + 45 + 35 = 110 segundos
• Paralelo: ~45 segundos (el más lento define el total) + tiempo de consolidación

Output esperado

## Reporte Comparativo de Módulos

### Análisis Individual

#### src/auth/ (30s)
- 8 archivos, ~450 LOC
- Issues: 2 (1 warning, 1 suggestion)
- Pattern: JWT middleware pattern

#### src/products/ (45s)
- 12 archivos, ~680 LOC
- Issues: 4 (1 critical, 2 warnings, 1 suggestion)
- Pattern: Repository pattern con SQLAlchemy

#### src/orders/ (35s)
- 10 archivos, ~520 LOC
- Issues: 3 (2 warnings, 1 suggestion)
- Pattern: State machine para order status

### Patrones Comunes
1. Los 3 módulos usan Pydantic v2 para validación
2. Error handling inconsistente — auth usa custom exceptions, los otros usan HTTPException
3. Ninguno tiene pagination implementada

### Top 5 Mejoras Prioritarias
1. [CRITICAL] src/products/routes.py:45 — SQL injection
2. [WARNING] Standardizar error handling — mismo patrón en los 3 módulos
3. [WARNING] Agregar pagination — products y orders lo necesitan
4. [SUGGESTION] Extraer middleware compartido de auth
5. [SUGGESTION] Agregar type hints faltantes en orders

La Variable de Entorno para Debugging

CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1

Si estás debuggeando un problema con la delegación paralela y necesitas que todo se ejecute en foreground (secuencialmente), puedes desactivar background tasks temporalmente:

CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 claude

Esto fuerza todos los subagents a ejecutarse en foreground, incluso si tienen background: true. Es útil cuando:

• Un subagent falla silenciosamente en background y quieres ver los errores en foreground
• Necesitas interactuar con los permisos de un subagent paso a paso
• Estás desarrollando un nuevo subagent y quieres ver su output en tiempo real

No la dejes activada en producción — pierdes todo el beneficio de la paralelización.

Troubleshooting

"Los subagents no se ejecutan en paralelo"

Causa: El prompt no es suficientemente explícito sobre la independencia de las tareas, o los subagents no tienen background: true.

Solución: Agrega background: true al frontmatter y usa un prompt explícito:

Ejecuta estos 3 subagents EN PARALELO, cada uno como tarea independiente:
1. module-analyzer para src/auth/
2. module-analyzer para src/products/
3. module-analyzer para src/orders/

"El subagent en background falla sin mensaje de error"

Causa: El subagent necesitó un permiso que no tenía pre-aprobado.

Solución: Verifica que todas las herramientas necesarias estén en el campo tools del frontmatter. Si necesitas debugging, ejecuta con CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 para ver los errores en foreground.

"Los worktrees no se limpian"

Causa: Un subagent con isolation: worktree crasheó antes de terminar normalmente.

Solución: Lista y limpia worktrees manualmente:

git worktree list
git worktree prune

"Dos subagents paralelos modificaron el mismo archivo"

Causa: Los subagents no tenían isolation: worktree o editaron el mismo archivo desde worktrees diferentes.

Solución: Si los subagents editan archivos potencialmente compartidos, asegúrate de que cada system prompt limite el scope a un directorio específico. Para máxima seguridad, usa worktrees Y restringe el scope:

## Constraints
ONLY modify files inside src/auth/. Do NOT touch any file outside this directory.

"El resultado consolidado pierde información"

Causa: Claude tiene que resumir los resultados de múltiples subagents, y la consolidación descarta detalles.

Solución: En el prompt de orquestación, especifica qué información debe preservarse:

Al consolidar, incluye TODOS los issues encontrados por cada subagent.
No omitas ningún hallazgo. El reporte consolidado debe tener la
información COMPLETA de los 3 análisis.

Ejercicios

Ejercicio 1: Tu primer subagent background (Fácil)

Crea un subagent file llamado quick-scanner.md con background: true que busca patrones de seguridad (hardcoded secrets, SQL injection) en un directorio especificado. Solo lectura. Ejecútalo contra tu proyecto.

---
name: quick-scanner
description: Scans a directory for security anti-patterns. Read-only, runs in background.
tools: Read, Glob, Grep
model: haiku
background: true
maxTurns: 8
---

## Role
Security scanner. Find hardcoded secrets and injection risks. NEVER modify files.

## Process
1. Grep for patterns: API_KEY, SECRET, PASSWORD, token in string literals
2. Grep for SQL string concatenation: f"SELECT, f"INSERT, .format(
3. Grep for eval(), exec(), os.system() with user input
4. Report findings

## Output Format
### Security Scan: [directory]
#### HIGH RISK
- **[file:line]** — [pattern found] — `[code snippet]`
#### MEDIUM RISK
- **[file:line]** — [pattern found]
#### Summary: [n] high, [n] medium

Ejercicio 2: Paralelizar dos análisis (Fácil)

Escribe el prompt que le dirías a Claude para ejecutar dos subagents en paralelo: uno analizando src/api/ y otro analizando src/models/. Ambos deben usar el module-analyzer de esta cápsula.

Analiza estos 2 módulos en paralelo usando subagents separados:
1. src/api/ — estructura, endpoints, patterns
2. src/models/ — estructura, relaciones, validación

Cada análisis debe ser independiente. Cuando ambos terminen,
compara los hallazgos y dame un resumen unificado.

Ejercicio 3: Diseñar frontmatter con worktree (Medio)

Diseña el frontmatter YAML completo para un subagent llamado style-fixer que corrige inconsistencias de estilo (quotes, trailing whitespace, import ordering) en un módulo específico. Debe ejecutarse en background con aislamiento via worktree. Justifica cada campo.

---
name: style-fixer
description: Fixes style inconsistencies in a module — quotes, whitespace, imports. Runs in isolated worktree.
tools: Read, Write, Edit, Grep, Glob
model: haiku
background: true
isolation: worktree
maxTurns: 15
---

Ejercicio 4: Identificar qué paralelizar (Medio)

Dado este flujo de trabajo, identifica qué tareas pueden ir en paralelo y cuáles deben ser secuenciales. Dibuja el flujo optimizado:

1. Actualizar los models de Pydantic en src/models/
2. Actualizar las routes que usan esos models en src/routes/
3. Actualizar los tests en tests/
4. Actualizar la documentación en docs/
5. Correr el linter en todo el proyecto
6. Correr los tests

Dependency analysis:
1. Models (no depende de nada)
2. Routes (depende de 1 — usa los models)
3. Tests (depende de 2 — testa las routes)
4. Docs (depende de 1 y 2 — documenta models y routes)
5. Linter (depende de 1, 2, 3 — necesita código final)
6. Tests run (depende de 1, 2, 3 — necesita código final)

Flujo optimizado:

Fase 1 (secuencial): Actualizar models
         ↓
Fase 2 (paralelo):
├── Actualizar routes   ──┐
└── Actualizar docs     ──┘ (docs puede basarse solo en models)
         ↓
Fase 3 (secuencial): Actualizar tests (necesita routes finales)
         ↓
Fase 4 (paralelo):
├── Correr linter  ──┐
└── Correr tests   ──┘ (independientes entre sí)

Ejercicio 5: Debugging de background failure (Difícil)

Un subagent con este frontmatter falla silenciosamente en background:

---
name: db-migrator
tools: Read, Grep
background: true
---

Run alembic upgrade head and verify the migration applied correctly.

Identifica el problema y propón la corrección.

---
name: db-migrator
tools: Read, Grep, Glob, Bash
background: true
maxTurns: 10
---

Ejercicio 6: Diseñar un flujo hybrid paralelo-secuencial (Difícil)

Diseña el flujo completo para esta tarea: "Necesito agregar autenticación JWT a un proyecto que tiene 4 routers (users, products, orders, admin). Cada router necesita endpoints protegidos."

Define: qué tareas van en paralelo, cuáles en secuencia, qué subagents necesitas, y qué campo de isolation usan.

Análisis de dependencias:
- La lógica de auth (JWT utils, middleware) debe existir ANTES de proteger endpoints
- Los 4 routers son independientes entre sí DESPUÉS de que auth existe
- Los tests deben ejecutarse DESPUÉS de que todos los routers estén actualizados

Flujo:

Fase 1 — SECUENCIAL:
  auth-implementer (no isolation)
  → Crear JWT utils, auth middleware, login/register endpoints
  → Debe terminar antes de Fase 2

Fase 2 — PARALELO (4 subagents con worktree):
  ├── router-protector (isolation: worktree) → proteger users router
  ├── router-protector (isolation: worktree) → proteger products router
  ├── router-protector (isolation: worktree) → proteger orders router
  └── router-protector (isolation: worktree) → proteger admin router

Fase 3 — SECUENCIAL:
  merge-coordinator (no isolation)
  → Verificar consistencia de los 4 routers protegidos
  → Ejecutar linter

Fase 4 — SECUENCIAL:
  code-tester (no isolation)
  → Ejecutar suite de tests completa

Subagents necesarios:
1. auth-implementer: tools=[Read,Write,Edit,Grep,Glob], model=sonnet
2. router-protector: tools=[Read,Write,Edit,Grep,Glob], background=true,
   isolation=worktree, model=sonnet
3. merge-coordinator: tools=[Read,Grep,Glob,Bash], model=haiku
4. code-tester: tools=[Bash,Read,Grep,Glob], model=haiku

Resumen

• La delegación paralela se activa con background: true en frontmatter, Ctrl+B en ejecución, o prompts explícitos que indican independencia
• isolation: worktree crea copias aisladas del repo para que agentes paralelos editen archivos sin conflictos
• Los subagents en background tienen permisos pre-aprobados — solo pueden usar herramientas del allowlist sin confirmación
• Si un subagent background falla por permisos, puedes resumirlo en foreground para debugging
• Los subagents no pueden lanzar subagents — la jerarquía es de un solo nivel
• El rango óptimo es 2-4 subagents paralelos — más allá, el overhead de coordinación supera el beneficio
• Usa CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 para forzar ejecución secuencial durante debugging
• No todo se paraleliza — tareas con dependencias, tareas muy cortas, y tareas que editan los mismos archivos no son buenas candidatas
• El patrón hybrid (paralelo → secuencial → paralelo) es el más potente en la práctica

Recursos Adicionales

1. Create Custom Subagents (Anthropic Docs) — Documentación oficial incluyendo background, isolation, maxTurns
2. Claude Code Sub-agents — Background Execution — Referencia de ejecución en background, permisos, y Ctrl+B
3. Git Worktrees Documentation — Referencia oficial de git worktrees
4. Claude Code CLI Reference — Variables de entorno como CLAUDE_CODE_DISABLE_BACKGROUND_TASKS
5. Claude Code Best Practices — Patrones de delegación y prompting
6. Claude Code Tips and Tricks — Tips para trabajo con subagents
7. Prompt Engineering: Be Clear and Direct — Claridad en prompts de delegación
8. Claude Models Documentation — Referencia de modelos para elegir haiku vs sonnet por costo en paralelismo

Siguiente cápsula: En la cápsula 03 aprenderás a coordinar los resultados de subagents paralelos — cómo diseñar dependency graphs, qué pasa cuando agentes terminan en momentos diferentes, estrategias de merge, y cómo git worktrees resuelven conflictos de escritura. La mecánica de lanzar agentes en paralelo ya la dominas; ahora aprenderás a juntar los resultados de forma coherente.