Delega en paralelo: los subagentes

¿Qué es un subagente?

Un subagente es un proceso separado que gestiona una tarea de forma independiente. Es la analogía más cercana a un «empleado IA»: le confías una misión delimitada, trabaja por su cuenta con el contexto y las herramientas necesarias, y luego te trae el resultado. El agente principal — con el que conversas — se convierte en un director de orquesta: divide el trabajo, delega y ensambla los resultados.

Tu skill principal /post va a delegar en subagentes y recolectar sus resultados. Como funcionan en paralelo, las tareas independientes (publicar en 4 plataformas) se hacen simultáneamente en lugar de una a una. Es el cambio de escala de este capítulo: pasamos de un asistente que hace las cosas rápido a un sistema que hace varias cosas al mismo tiempo.

El verdadero superpoder: el contexto aislado

El ahorro de tiempo es la ventaja visible, pero hay una segunda, más sutil e igual de valiosa: cada subagente trabaja en su propia ventana de contexto. Recuerda el capítulo 2: el ruido degrada las respuestas. Cuando un subagente adapta tu post para Instagram, carga las reglas de Instagram, las muestras de Instagram, hace sus pruebas — y todo ese volumen no contamina la conversación principal. El agente principal solo recibe el resultado final, limpio.

Sin subagentes, publicar en 4 plataformas llenaría tu ventana de contexto con cuatro veces todo ese trabajo intermedio, y la sesión se volvería confusa mucho antes del final. Con ellos, tu conversación principal sigue siendo un cuaderno de bitácora legible: misión, delegación, resultados. Por eso los subagentes son útiles incluso para tareas secuenciales voluminosas — explorar una gran base de código, analizar diez documentos — no solo para el paralelismo.

Definir subagentes especializados (opcional pero potente)

Claude Code puede lanzar subagentes genéricos al vuelo — eso es lo que hará tu skill. Pero también puedes definir subagentes nombrados y especializados, con el comando /agents o creando archivos en .claude/agents/. Cada archivo describe un rol: su nombre, su descripción (que sirve a Claude para saber cuándo solicitarlo), las herramientas a las que tiene derecho, y su prompt de sistema.

---
name: redactor-instagram
description: Adapta un contenido al formato Instagram (texto + hashtags) en la voz de la marca. Usar para toda publicación en Instagram.
tools: Read, Write, Bash
---

Eres el especialista de Instagram de la marca.
Lees brand-voice.md antes de toda redacción.
Formato: gancho fuerte, texto aireado, 3 a 5 hashtags al final.
Nunca publicas sin un media asociado.

El interés de la especialización: un subagente «redactor de Instagram» con un rol preciso y herramientas restringidas es más fiable que un generalista, exactamente como en un equipo humano. Y limitar sus herramientas (sin acceso a red para un revisor, por ejemplo) es una medida de seguridad gratuita. Para el proyecto de Lea, la skill con subagentes al vuelo basta — pero guarda esta carta en mente para tus sistemas más ambiciosos.

Skill, hook, subagente: ¿quién hace qué?

A estas alturas del curso, tienes tres mecanismos de extensión. Se parecen de lejos, pero cada uno responde a una pregunta diferente — y confundirlos es el error más común de los principiantes:

Los tres se combinan naturalmente: la skill describe el procedimiento, que delega en subagentes, cuyas acciones pasan todas por los hooks. Es exactamente la arquitectura del sistema de Lea.

Pasar la skill a multiplataforma

actualiza la skill /post para soportar «all»:
/post "tema" all

cuando la plataforma es «all»:
- crea el visual una sola vez
- lanza un subagente por plataforma (twitter, linkedin, instagram, facebook)
- cada subagente adapta el texto al formato, los límites y la voz de la plataforma
- todos publican en paralelo
- registra todos los resultados en el journal

Fíjate en el detalle «crea el visual una sola vez»: es una decisión de arquitectura. La generación del visual es costosa y el resultado es compartido — por eso permanece en el agente principal, antes de la delegación. Solo el trabajo realmente independiente (adaptar el texto, publicar, registrar) sale en paralelo. Identificar lo que es compartido y lo que es independiente es el corazón del diseño de un sistema paralelo.

Lanza después: /post "nuestros compromisos residuo cero" all. Claude crea un visual, redacta las variantes según tu voz, te pide validación y luego lanza los subagentes. Verás varios bloques de tareas ejecutándose simultáneamente en la interfaz — es tu equipo trabajando.

flowchart TD
  M["/post tema all"] --> V["Visual creado una sola vez"]
  V --> S1["Subagente Twitter"]
  V --> S2["Subagente LinkedIn"]
  V --> S3["Subagente Instagram"]
  V --> S4["Subagente Facebook"]
  S1 --> J["Journal + URLs"]
  S2 --> J
  S3 --> J
  S4 --> J

¿Por qué no en secuencia?

Cada publicación es asíncrona: Claude envía el post y luego consulta la API cada pocos segundos hasta el estado «publicado» (5 a 30 s según la plataforma). 4 posts en serie = hasta 2 minutos de espera acumulada, durante los cuales no pasa nada útil. 4 subagentes en paralelo = una sola espera, la del más lento.

Cada subagente gestiona su propio ciclo asíncrono: enviar, consultar, procesar la respuesta, registrar. La redacción de las variantes y la validación, en cambio, permanecen en el agente principal — validas una vez, y luego todo sale en paralelo. Y si un subagente falla (API caída, cuota superada), los otros tres terminan normalmente: solo retomas la plataforma fallida, no todo el lote.

Los límites del paralelismo

El reflejo «paralelizarlo todo» sería un error. El paralelismo tiene un coste: cada subagente consume sus propios tokens, y orquestar tiene su propia complejidad. Solo vale la pena si las tareas son realmente independientes (ninguna necesita el resultado de otra) y lo bastante largas para que la espera acumulada pese. Adaptar cuatro posts: perfecto. Tres etapas donde cada una depende de la anterior (investigar → redactar → publicar): ninguna paralelización posible, es una cadena.

La buena prueba: dibuja tu flujo como el diagrama de arriba. Las ramas que salen del mismo nodo sin tocarse después son paralelizables; todo lo que se encadena verticalmente no lo es. Dos minutos de esquema evitan horas de arquitectura innecesariamente compleja.