5. Messaging entre Teammates y Resolución de Conflictos

Descripción

Un equipo donde los miembros no se comunican es un grupo de individuos trabajando en paralelo — no un equipo. Hasta ahora tienes un team lead que asigna tareas y teammates que ejecutan. Pero ¿qué pasa cuando el frontend-agent necesita saber la forma exacta de la respuesta del backend-agent? ¿Cuando dos teammates modifican archivos que interactúan? ¿Cuando uno termina antes que los demás y no hay qué asignarle?

En esta cápsula aprenderás los mecanismos de comunicación entre teammates: cómo intercambian información a través del team lead, cómo se resuelven conflictos cuando dos agentes producen resultados incompatibles, qué hace el team lead cuando un teammate queda idle, y los failure modes más comunes de un equipo de agentes. Estos patrones son la diferencia entre un equipo que produce resultados coherentes y uno que produce fragmentos inconexos.

⚠️ FEATURE EXPERIMENTAL

Los mecanismos de messaging entre teammates dependen de la implementación de Agent Teams en Claude Code. El modelo conceptual (team lead como intermediario de comunicación) es estable. Los patrones de esta cápsula aplican tanto con Agent Teams formales como con la alternativa manual del coordinador.

Última verificación: Marzo 2026

Cómo se Comunican los Teammates

El team lead como intermediario

Los teammates no se comunican directamente entre sí. Toda la comunicación pasa por el team lead:

frontend-agent ←──→ Team Lead ←──→ backend-agent
                        ↑
                    (intermediario)

Cuando el frontend-agent necesita información del backend-agent:

1. frontend-agent reporta: "BLOCKED — necesito el schema de ProfileResponse"
2. Team lead lee el reporte de frontend-agent
3. Team lead verifica si backend-agent ya produjo ese schema
4. Si sí → team lead pasa la información al frontend-agent
5. Si no → team lead asigna a backend-agent: "Publica ProfileResponse schema"
6. Cuando backend-agent termina → team lead pasa el resultado a frontend-agent

Tipos de comunicación

1. Output forwarding — pasar resultados:

El tipo más común. El team lead toma el output de un teammate y lo incluye como contexto al asignar una tarea a otro:

## Para frontend-agent:
Task T4: Implementa ProfilePage.

Context from backend-agent (T2):
- GET /api/profile returns ProfileResponse:
  { id: int, username: str, email: str, avatar_url: str | None }
- Endpoint is at src/api/routes/profile.py
- Auth required: Bearer token in header

El team lead no solo pasa el output — lo procesa y extrae la información relevante para el siguiente teammate.

2. Query — un teammate necesita información:

frontend-agent: "¿Cuál es el formato de error del backend? 
                 Necesito saber qué campos tiene el error response 
                 para mostrar mensajes apropiados."

Team lead:
  → Verifica si backend-agent ya definió el formato
  → Si sí, extrae la información y la pasa
  → Si no, crea una micro-tarea para backend-agent:
    "Define y documenta el formato estándar de error response"

3. Notification — informar de un cambio:

backend-agent: "Cambié el nombre del campo 'user_name' a 'username' 
                en ProfileResponse."

Team lead:
  → Verifica si algún otro teammate ya usó 'user_name'
  → Si frontend-agent ya implementó con 'user_name', 
    asigna tarea de actualización
  → Si no, simplemente registra para futura referencia

Instrucciones de messaging para el team lead

## Communication Management

### When forwarding outputs
- Extract ONLY the relevant information for the receiving teammate
- Include: data schemas, file paths, API contracts, decisions made
- Exclude: internal implementation details, tool calls, reasoning

### When a teammate queries for information
1. Check if the answer exists in a prior teammate's output
2. If yes → forward the relevant part
3. If no → create a micro-task for the teammate who can answer
4. Micro-tasks have HIGH priority (they unblock other teammates)

### When a teammate reports a change
1. Check if the change affects other teammates' work
2. If yes → notify affected teammates with specific impact
3. If no → log and continue

### Communication Log
After each communication, log:
- FROM: [teammate]
- TO: [teammate]  
- TYPE: output_forward | query | notification
- CONTENT: [summary]

Resolución de Conflictos

Escenario: outputs contradictorios

Dos teammates producen resultados que se contradicen:

backend-agent: "Creé GET /profile que retorna { user: { name, email } }"
frontend-agent: "Creé ProfilePage esperando { profile: { username, email } }"

Dos inconsistencias:

1. Campo raíz: user vs profile
2. Nombre del campo: name vs username

El proceso de resolución

## Conflict Resolution Process

When two teammates produce incompatible results:

### Step 1: Identify the conflict
- Compare outputs side by side
- List specific incompatibilities
- Determine which teammate's output is the "source of truth"

### Step 2: Decide who adjusts
Priority for "source of truth":
1. The teammate closer to the data source wins (backend > frontend for API)
2. The teammate who completed first wins (if both are equal authority)
3. The team lead decides based on project conventions

### Step 3: Assign correction
Assign a correction task to the teammate who must adjust:
"CORRECTION T4b: Update ProfilePage to use { user: { name, email } } 
 instead of { profile: { username, email } }. 
 Backend's response format is the source of truth."

### Step 4: Verify
After correction, verify both sides are compatible.

Reglas de prioridad en conflictos

Instrucciones de conflict resolution para el team lead

## When Conflict is Detected

1. PAUSE execution of dependent tasks
2. ANALYZE: What exactly is inconsistent?
3. DECIDE: Who adjusts? (use priority rules)
4. ASSIGN: Correction task to the adjusting teammate
5. VERIFY: After correction, confirm compatibility
6. RESUME: Unblock dependent tasks

NEVER let a conflict pass unresolved — downstream tasks will 
inherit the inconsistency and amplify it.

TeammateIdle: Qué Hacer Cuando un Agente Termina Antes

El escenario

Task board status:
T1 [DONE] ✅ — backend-agent
T2 [IN_PROGRESS] 🔄 — backend-agent (working on endpoint)
T3 [DONE] ✅ — frontend-agent
T4 [BLOCKED] 🔒 — frontend-agent (waiting for T2)

frontend-agent is IDLE — no pending tasks available.

El frontend-agent terminó su tarea (T3) pero su siguiente tarea (T4) está bloqueada por T2. ¿Qué hace el team lead?

Estrategias para TeammateIdle

1. Pre-fetch work — preparar sin ejecutar:

When a teammate is idle and all their tasks are blocked:
1. Check if there's preparatory work for blocked tasks
2. Assign a READ-ONLY pre-fetch task:
   "While waiting for T2, read the existing components in 
    src/components/ and plan the structure for T4. 
    Do NOT create or modify files yet."

Esto no viola dependencias porque no produce output — solo prepara al teammate para trabajar más rápido cuando se desbloquee.

2. Documentation tasks:

When a teammate is idle:
- Assign documentation for completed tasks
- "Document the components you created in T3:
   - Props interfaces
   - Usage examples
   - Edge cases handled"

Aprovecha el tiempo idle para trabajo útil que no requiere dependencias.

3. Code review cruzado:

When a teammate is idle:
- Assign a review of another teammate's completed work
- "Review the API endpoints created by backend-agent in T1.
   Verify the response shapes match what you'll need in T4.
   Report any incompatibilities."

Esto puede detectar conflictos temprano, antes de que el teammate empiece su tarea dependiente.

4. Esperar (legítimo en algunos casos):

If no preparatory work is possible:
- Log: "[teammate] is idle, waiting for [dependency]"
- This is acceptable — not all idle time needs to be filled
- Don't create busywork that adds complexity without value

Instrucciones de idle management para el team lead

## TeammateIdle Protocol

When a teammate completes all assigned tasks and has no PENDING tasks:

1. CHECK: Are there BLOCKED tasks for this teammate?
   - If yes → Can pre-fetch work be assigned? → Assign read-only task
   - If no → This teammate is DONE for this request

2. OPTIONAL PRODUCTIVE TASKS (in order of value):
   a. Review another teammate's output for compatibility
   b. Document completed work
   c. Analyze the codebase for potential issues related to the request

3. LOG: "frontend-agent idle at [timestamp]. Assigned: [task or 'waiting']"

4. RESUME: When dependency completes, immediately assign the unblocked task

RULE: Idle tasks MUST be low-effort and NEVER delay critical path.
Do not assign a 30-minute documentation task if the dependency 
might complete in 5 minutes.

Failure Modes del Equipo

Failure Mode 1: Teammate fails

T2: GET /profile → backend-agent → FAILED
Error: "Cannot create endpoint — model User doesn't exist yet"

Causa: Dependencia no detectada (T2 necesitaba T1 pero no se declaró).

Resolución del team lead:

1. Analyze: T2 failed because User model doesn't exist
2. Diagnosis: Missing dependency — T2 should have depended on a 
   model creation task
3. Action: Create T1b: "Create User model" → assign to backend-agent
4. Update: T2 now depends on T1b
5. Execute T1b, then retry T2

Failure Mode 2: Teammate loops

T3: Implement validation → backend-agent → DONE
Team lead: "Output doesn't match spec, fix these issues..."
T3: Retry → backend-agent → DONE
Team lead: "Still doesn't match, now it has different issues..."
T3: Retry again...

Causa: El team lead y el teammate tienen expectativas diferentes o el spec es ambiguo.

Resolución:

## Loop Detection

If a task has been retried 2+ times:
1. STOP retrying
2. Compare: original spec vs teammate output vs team lead feedback
3. Identify: Is the spec ambiguous? Is the team lead's feedback 
   contradictory? Is the teammate misunderstanding?
4. If ambiguous spec → clarify and retry once more
5. If contradictory feedback → team lead acknowledges and adjusts
6. If persistent misunderstanding → escalate to user with details

MAXIMUM RETRIES: 2 per task. After that, escalate.

Failure Mode 3: Cascading failure

T1 → DONE
T2 → DONE (but output has a subtle bug)
T4 → DONE (built on T2's buggy output — inherited the bug)
T5 → FAILED (because T4's bug caused a crash)

Causa: El team lead no verificó la calidad de T2 antes de unblockear T4.

Resolución:

## Quality Gates

After each task completes, before unblocking dependents:
1. Read the teammate's output report
2. Quick verification:
   - Does the output match the task description?
   - Are files in the correct directories?
   - Does the output format match expectations?
3. If verification fails → return to teammate for fixes
4. Only unblock dependents after verification passes

For cascading failures:
1. Identify the root cause (which task introduced the bug?)
2. Fix the root cause task first
3. Re-run affected downstream tasks
4. Do NOT patch — fix at the source

Failure Mode 4: Resource contention

backend-agent: modifying src/api/router.py (adding route)
frontend-agent: reading src/api/router.py (checking endpoints)

No es un conflicto técnico (uno lee, otro escribe), pero el frontend-agent puede read un state incompleto.

Resolución:

## File Access Coordination

If two teammates need the same file:
1. WRITE wins over READ — let the writer finish first
2. After write completes, reader gets the updated version
3. If both need to WRITE — this is a boundary violation. 
   Only one teammate should own each file.

Preventive: Ensure boundaries don't overlap (capsule 03).

Failure Mode 5: Team lead context overflow

Con múltiples teammates reportando resultados extensos, el team lead puede exceder su ventana de contexto.

Resolución:

## Context Management for Team Lead

1. Instruct teammates to keep reports concise:
   "Maximum 20 lines per task report"
2. After processing a teammate's output, summarize before forwarding:
   Instead of forwarding the full report, extract key information
3. Use the progress log format, not full reports:
   "T2 DONE: Created GET /profile (src/api/routes/profile.py), 
    returns ProfileResponse with 4 fields"
4. If context is getting full, the team lead should consolidate:
   Summarize all completed tasks in 1-2 lines each

Patrón Completo: Communication Protocol

Aquí está el protocolo de comunicación completo para incluir en el system prompt del team lead:

## Communication Protocol

### Outbound (team lead → teammate)
When assigning a task, ALWAYS include:
1. Task ID and clear description
2. Context from prior tasks (extracted, not raw output)
3. Files to work in
4. Expected output format
5. Dependencies to be aware of

### Inbound (teammate → team lead)
Expect from each teammate:
1. Task Report with status (DONE/PARTIAL/BLOCKED/FAILED)
2. Files created/modified
3. Key decisions made
4. Dependencies needed (if BLOCKED)
5. Errors encountered (if FAILED)

### Cross-team (teammate A needs info from teammate B)
1. Teammate A reports BLOCKED with specific question
2. Team lead checks if answer exists in prior outputs
3. If yes → forward relevant information
4. If no → create micro-task for teammate B
5. After answer → unblock teammate A with context

### Conflict (two teammates disagree)
1. Pause dependent tasks
2. Compare outputs side by side
3. Apply priority rules (data source > consumer)
4. Assign correction to the lower-priority teammate
5. Verify compatibility
6. Resume

### Failure (teammate reports error)
1. Read error report
2. Classify: recoverable or blocking
3. If recoverable → retry with additional context (max 2)
4. If blocking → escalate to user
5. Update task board: mark dependent tasks as BLOCKED

### Idle (teammate has no work)
1. Assign pre-fetch or documentation task
2. Or: assign cross-review of another teammate's work
3. Or: wait (legitimate if dependency is almost done)
4. Never assign work that delays the critical path

Alternativa Manual: Messaging sin Agent Teams

Sin Agent Teams formales, el coordinador gestiona la comunicación explícitamente:

---
name: coordinator
tools: Agent(frontend-agent), Agent(backend-agent), Read, Glob, Grep
model: sonnet
maxTurns: 60
---

## Communication as Coordinator

### Passing context between teammates

When delegating to teammate B after teammate A completes:

"You are backend-agent. Here is your task:

TASK: T3 — Create PUT /profile endpoint
DEPENDS ON: T1 (schema — DONE)

CONTEXT FROM PRIOR TASKS:
- User model defined in src/models/user.py (from T1)
- Fields: id (int), username (str), email (str), avatar_url (str|None)
- GET /profile already exists at src/api/routes/profile.py (from T2)

DELIVERABLE: PUT endpoint that updates user profile fields.
Report: files modified, response format, validation rules."

### Resolving conflicts manually

If two teammates produce incompatible outputs:

1. Read both outputs fully
2. Identify the specific incompatibility  
3. Decide which teammate adjusts (backend is source of truth for API)
4. Delegate a correction task with explicit instructions:
   "CORRECTION: The ProfilePage uses { profile: { username } } but
    the API returns { user: { name } }. Update ProfilePage to match
    the API response format: { user: { name, email } }."

La diferencia: sin Agent Teams, todo esto es manual en el prompt de delegación. Con Agent Teams, el team lead tiene protocolos establecidos. El resultado es similar para equipos pequeños, pero la alternativa manual requiere prompts más detallados.

Troubleshooting

"Los teammates no reciben contexto de tareas anteriores"

Causa: El team lead delega sin incluir outputs de tareas previas.

Solución: Agrega una regla enfática:

MANDATORY: When assigning a task that has dependencies, 
ALWAYS include relevant outputs from completed dependencies.

For each dependency:
- What was the task?
- What files were created/modified?
- What data formats were defined?
- What decisions were made?

Without this context, the teammate will make incompatible decisions.

"Los conflictos se detectan demasiado tarde"

Causa: El team lead no verifica compatibilidad entre outputs.

Solución: Agrega un quality gate después de cada tarea:

After EACH task completion:
1. Read the output
2. Compare with outputs of related tasks (same resource, same files)
3. If incompatibility found → resolve BEFORE assigning next task
4. Log: "Compatibility check: T[x] output is compatible with T[y]"

"Un teammate queda idle indefinidamente"

Causa: Su única tarea pendiente tiene una dependencia que está fallando o tardando mucho.

Solución: Agrega un timeout y escalation:

If a teammate has been idle for more than 3 task completions 
by other teammates:
1. Check why the blocking dependency is not done
2. If the blocker is IN_PROGRESS → wait
3. If the blocker is FAILED → resolve or escalate
4. Consider: can the idle teammate help unblock?
   (e.g., frontend-agent reviews API design to speed up backend)

"El team lead pierde track del estado del equipo"

Causa: Demasiadas tareas y comunicaciones sin registro.

Solución: Agrega un status display obligatorio:

After EVERY action (assign, complete, fail, conflict):
Display the current state:

📋 Team Status
- frontend-agent: [IDLE | WORKING on T4 | BLOCKED]
- backend-agent: [IDLE | WORKING on T2 | BLOCKED]

Task Board:
T1 [DONE] ✅  T2 [PROGRESS] 🔄  T3 [BLOCKED] 🔒
T4 [PENDING] ⏳  T5 [BLOCKED] 🔒

"Los teammates generan reportes demasiado largos que saturan el contexto"

Causa: Sin límite de tamaño en los Task Reports.

Solución: Agrega una restricción explícita al output format de cada teammate:

## Output Constraints
- Task Report: maximum 20 lines
- List only files created/modified (not full content)
- Summary in 1-2 sentences
- Detailed code belongs in the files, not in the report

Ejercicios

Ejercicio 1: Diseñar un mensaje de contexto (Fácil)

El backend-agent completó T2 (GET /users endpoint). Ahora el team lead debe asignar T4 (UserList component) al frontend-agent. Escribe el mensaje de asignación incluyendo el contexto extraído del output de T2.

## Task Assignment for frontend-agent

**Task:** T4 — Implement UserList component
**Depends on:** T2 (GET /users — DONE ✅)

### Context from T2 (backend-agent):
- Endpoint: GET /api/users
- Response format:
  ```json
  {
    "users": [
      { "id": 1, "name": "Alice", "email": "alice@example.com", "role": "admin" }
    ],
    "total": 42,
    "page": 1,
    "per_page": 20
  }

</details>

### Ejercicio 2: Resolver un conflicto (Fácil)

El backend-agent creó `POST /api/users` que retorna `{ "user_id": 123, "status": "created" }`. El frontend-agent creó el formulario esperando la respuesta `{ "id": 123, "message": "User created" }`. Escribe la resolución del team lead.

<details>
<summary>Ver solución</summary>

```markdown
## Conflict Resolution

### Incompatibility detected:
- Backend response: { "user_id": 123, "status": "created" }
- Frontend expects: { "id": 123, "message": "User created" }
- Differences: user_id vs id, status vs message

### Decision:
Backend is source of truth for API responses.
Frontend must adjust to match the actual API response.

### Correction task for frontend-agent:
"CORRECTION T3b: Update the registration form's success handler.

The POST /api/users endpoint returns:
  { "user_id": 123, "status": "created" }

NOT { "id": 123, "message": "User created" } as you implemented.

Update:
1. Change response parsing to use user_id instead of id
2. Change success message to use status instead of message
3. Verify the form works with the actual API response format"

### Verification:
After correction, confirm frontend uses user_id and status fields.

Ejercicio 3: Protocolo de idle management (Medio)

El equipo tiene 3 teammates. frontend-agent terminó T3 y su siguiente tarea T6 depende de T4 (backend-agent, IN_PROGRESS) y T5 (db-dev, DONE). Diseña 3 opciones productivas para el frontend-agent idle y recomienda una.

"Read the output of T5 (db-dev) and prepare for T6. 
 Analyze the data model created in T5. Plan the component 
 structure for T6 but do NOT create files yet."

"Review the data types created by db-dev in T5. 
 Verify the TypeScript interfaces match what you'll 
 need for T6. Report any incompatibilities."

"Document the components you created in T3:
 - Props interfaces with descriptions
 - Usage examples
 - Edge cases handled"

Ejercicio 4: Gestionar un cascading failure (Medio)

T1 (DONE) → T2 (DONE, con bug sutil) → T4 (DONE, hereda bug) → T5 (FAILED porque el bug causó crash). Escribe el plan de resolución del team lead paso a paso.

## Cascading Failure Resolution Plan

### Step 1: Identify root cause
T5 failed with crash. Read T5's error report.
Error points to data from T4. Read T4's output.
T4 used data from T2. Read T2's output.
Root cause: T2 produced a field with wrong type 
(string instead of int for user_id).

### Step 2: Fix at the source
Assign correction to the teammate who did T2:
"CORRECTION T2b: Fix user_id type in ProfileResponse.
 Current: user_id: str (incorrect)
 Expected: user_id: int
 File: src/api/schemas/profile.py"

### Step 3: Re-run affected downstream
After T2b completes:
- T4 must be re-run (it consumed T2's output)
  "RE-RUN T4b: Rebuild ProfilePage using corrected T2b output.
   user_id is now int, not str."
- T5 must be re-run after T4b
  "RE-RUN T5b: Retry ProfileForm with corrected data from T4b."

### Step 4: Verify the fix propagated
After all re-runs:
- Verify T2b: user_id is int ✅
- Verify T4b: component uses int user_id ✅
- Verify T5b: form works without crash ✅

### Step 5: Post-mortem
"Root cause: T2 had a type error (user_id: str instead of int).
 Impact: 3 tasks affected (T2, T4, T5).
 Prevention: Added type verification to quality gate."

### Lesson: Quality gates after each task would have 
caught this at T2, preventing the cascade.

Ejercicio 5: Communication protocol completo (Difícil)

Escribe un communication protocol para un equipo de 3 teammates (ui-dev, api-dev, db-dev) trabajando en un e-commerce. Incluye: outbound format, inbound format, conflict rules con 3 escenarios específicos, idle strategy, y failure escalation.

## E-commerce Team Communication Protocol

### Outbound (team lead → teammate)
Format:
"TASK: [ID] — [description]
 AGENT: [teammate name]
 DEPENDS: [task IDs or 'none']
 CONTEXT: [extracted data from dependencies]
 FILES: [specific paths to create/modify]
 DELIVER: [expected output]"

### Inbound (teammate → team lead)
Expected format:
"TASK: [ID]
 STATUS: DONE | PARTIAL | BLOCKED | FAILED
 FILES: [created/modified list]
 OUTPUT: [key data: schemas, endpoints, components]
 NOTES: [decisions, questions, blockers]"

### Conflict Rules

Scenario 1: Product schema disagreement
- db-dev defines Product with price: Decimal
- api-dev serializes price as float
- Resolution: db-dev wins (data integrity). api-dev converts 
  Decimal to string in API response to preserve precision.

Scenario 2: Cart endpoint ownership
- api-dev created POST /cart in routes/cart.py
- ui-dev created a mock POST /cart in frontend mock server
- Resolution: api-dev owns real endpoints. ui-dev uses api-dev's 
  endpoint. Delete frontend mock.

Scenario 3: Naming inconsistency
- db-dev: product_category (snake_case in DB)
- api-dev: productCategory (camelCase in API)
- ui-dev: ProductCategory (PascalCase in React)
- Resolution: Each layer uses its convention. API serializer 
  translates between DB snake_case and JSON camelCase.

### Idle Strategy
Priority order:
1. Cross-review of related teammate's output
2. Pre-fetch for blocked task
3. Write tests for completed work (if test-capable)
4. Wait (if dependency is almost done)

### Failure Escalation
- 1st failure → retry with context
- 2nd failure → different approach or additional context
- 3rd failure → escalate to user with full report
- NEVER retry more than 2 times for the same task

Ejercicio 6: Simular una sesión de team lead (Difícil)

Sin ejecutar Claude Code, simula en papel (o en un doc) una sesión completa de un team lead con 2 teammates y 5 tareas. Para cada step, escribe: qué haría el team lead, qué delegaría, qué recibiría, y cómo actualizaría el task board. Incluye al menos un conflicto y un caso de idle.

## Simulation: User Profile Feature

Team: team-lead, frontend-agent, backend-agent
Request: "Implement user profile page with edit capability"

### Step 1: Generate task board
Team lead generates:
| ID | Task | Agent | Depends | Status |
| T1 | User schema | backend | none | PENDING |
| T2 | GET /profile | backend | T1 | BLOCKED |
| T3 | PUT /profile | backend | T1 | BLOCKED |
| T4 | ProfilePage | frontend | T2 | BLOCKED |
| T5 | EditForm | frontend | T3, T4 | BLOCKED |

### Step 2: Assign T1
Team lead: "T1 to backend-agent: Create User Pydantic schema"
frontend-agent: IDLE (no pending tasks)
Team lead idle action: "frontend-agent, review existing components 
 for patterns we should follow in T4/T5"

### Step 3: T1 completes
backend-agent: "DONE. UserSchema in src/schemas/user.py"
Team lead: Unblocks T2, T3 → both PENDING
Assigns T2 to backend-agent (HIGH priority)
Assigns... T3 also to backend-agent. But backend is busy with T2.
→ T3 stays PENDING until T2 done.
frontend-agent: Still IDLE. Team lead: "pre-fetch for T4"

### Step 4: T2 completes
backend-agent: "DONE. GET /profile returns { name, email, bio }"
Team lead: Unblocks T4 → PENDING
Assigns T3 to backend-agent
Assigns T4 to frontend-agent WITH context from T2

### Step 5: CONFLICT
T3 completes: backend "PUT /profile accepts { name, email }"
T4 completes: frontend "ProfilePage shows name, email, AND bio"
Conflict: PUT doesn't accept bio but frontend shows it.
Team lead: "Backend is source of truth. frontend-agent, note that 
 bio is read-only (not editable). Adjust T5 to exclude bio from form."

### Step 6: T5 assigned with correction
Team lead: "T5 to frontend-agent: EditForm for name and email ONLY. 
 Bio is displayed in T4 but not editable."
Result: T5 DONE.

### Step 7: Final
Team lead: All tasks DONE. Final report.

Resumen

• Los teammates no se comunican directamente — toda comunicación pasa por el team lead como intermediario
• Hay 3 tipos de comunicación: output forwarding (pasar resultados), query (pedir información), y notification (informar cambios)
• Los conflictos se resuelven con reglas de prioridad: la fuente de datos gana sobre el consumidor, CLAUDE.md gana sobre preferencias individuales
• TeammateIdle se gestiona con tareas productivas: pre-fetch, cross-review, o documentación — pero nunca trabajo que retrase el critical path
• Los 5 failure modes principales: teammate fails, teammate loops, cascading failure, resource contention, y context overflow
• Quality gates después de cada tarea previenen cascading failures — verificar antes de unblockear
• El communication protocol (outbound, inbound, cross-team, conflict, failure, idle) es el contrato que hace predecible al equipo
• Sin Agent Teams, toda esta comunicación se gestiona manualmente en los prompts de delegación del coordinador

Recursos Adicionales

1. Create Custom Subagents (Anthropic Docs) — Documentación oficial de subagents y comunicación
2. Claude Code Best Practices — Buenas prácticas de delegación y coordinación
3. Multi-Agent Orchestration — Patrones de coordinación multi-agente
4. Prompt Engineering: Be Clear and Direct — Claridad en comunicación entre agentes
5. Claude Code CLI Reference — Referencia de CLI para foreground/background
6. Claude Code Settings — Configuración de context management
7. Conflict Resolution in Distributed Systems — Fundamentos teóricos de resolución de conflictos
8. Claude Code Overview — Contexto general de Claude Code

Siguiente cápsula: En la cápsula 06 construirás el proyecto del módulo: un equipo funcional de 3 agentes (team lead + frontend-agent + backend-agent) con un task board de 5+ tareas y dependencias reales. Integrarás todo lo aprendido en las cápsulas 02-05: configuración del team lead, definición de teammates con boundaries, task board con dependencias, y protocols de comunicación y conflict resolution.