13 agentes Claude: boss agent, ciclo de crítica y costes

TL;DR: Un equipo de 13 agentes Claude con roles especializados y revisión cruzada produce outputs más consistentes que un agente único, al precio de mayor complejidad y coste de tokens. Este artículo explica la arquitectura completa: cómo definir roles, configurar el boss agent, hacer que los agentes se critiquen entre sí, persistir el estado entre sesiones y calcular si el ROI tiene sentido para tu caso.

El problema con delegar a un agente único

Un agente que escribe también aprueba lo que ha escrito. No hay segunda perspectiva, no hay verificación de hechos, no hay crítica de estructura. En producción, esto genera inconsistencias difíciles de detectar sin supervisión humana constante.

El patrón que ha emergido con fuerza en la comunidad es distinto: en lugar de supervisar tú el output, delegas la supervisión a otros agentes. Es el mismo razonamiento que usamos cuando pedimos a un compañero que revise nuestro código antes de hacer merge: dos perspectivas detectan más errores que una.

Con la llegada de Claude Code Agent Teams y las mejoras de Claude Opus 4.6, este patrón ha pasado de ser teoría a ser implementable sin infraestructura costosa. Un equipo de 13 agentes con roles definidos y ciclo de revisión integrado es el caso de uso que más tracción está generando en pipelines de contenido y revisión de código.

¿Qué es un equipo multi-agente con ciclo de crítica?

Un equipo multi-agente es un sistema donde varios agentes especializados colaboran hacia un objetivo común. Cada agente tiene un rol único, un contrato de input/output claro y puede comunicarse con otros agentes directamente, sin que el humano actúe como intermediario.

El ciclo de crítica añade una capa de revisión entre la producción y el output final: los agentes Critic no revisan su propio trabajo, sino el de otros Writers. Ese cruce forzado es lo que detecta errores que un único agente nunca vería en su propio output.

Claude Code Agent Teams es la funcionalidad experimental que hace posible esta arquitectura de forma nativa. A diferencia de los subagentes clásicos, que solo reportan resultados al agente padre, los teammates de Agent Teams pueden enviarse mensajes entre sí, reclamar tareas de una lista compartida y coordinarse sin que el lead tenga que gestionar cada interacción.

La arquitectura de 13 agentes

La distribución que funciona en pipelines de contenido reales separa claramente producción, revisión y síntesis:

Rol	Cantidad	Función	Modelo recomendado
Boss Agent (coordinador)	1	Asigna tareas, gestiona fases, sintetiza resultados. Nunca produce contenido.	Opus
Writer Agent	3	Cada uno produce un borrador desde una perspectiva diferente: técnica, divulgativa, SEO-first.	Sonnet
Critic Agent	3	Cada Critic revisa el borrador de un Writer distinto al suyo. Nunca el propio.	Sonnet
Fact-checker Agent	2	Verifican datos, cifras y afirmaciones técnicas del borrador seleccionado.	Sonnet
Style Agent	2	Coherencia de voz, consistencia del registro y revisión de marca.	Sonnet
SEO Agent	1	Optimiza estructura, keywords y metadatos del draft final.	Haiku
Editor Agent	1	Integra todos los feedbacks y produce el entregable final.	Opus

El Boss Agent nunca produce contenido directamente. Ese es el principio central: si el coordinador empieza a opinar sobre el estilo o la precisión técnica, pierde su función de árbitro. Su único trabajo es saber cuándo avanzar de fase y cuándo escalar al humano.

Paso 1: habilitar Agent Teams y configurar el Boss Agent

Agent Teams es experimental y está desactivado por defecto. Habilítalo en tu ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

El Boss Agent necesita un CLAUDE.md con instrucciones de coordinación muy explícitas. La vaguedad es el principal punto de fallo en sistemas multi-agente: si el coordinador no tiene criterios claros de avance, el pipeline se estanca.

# Boss Agent - Pipeline de Contenido

## Rol
Coordinas el equipo de 13 agentes. NUNCA produces contenido directamente.
Solo puedes: crear tareas, asignar agentes, verificar resultados, enviar mensajes entre fases.

## Fases (ejecutar en orden estricto)
1. DRAFT: Lanzar Writer-1, Writer-2, Writer-3 en paralelo
2. REVIEW: Critic-1 revisa Writer-2, Critic-2 revisa Writer-3, Critic-3 revisa Writer-1
3. SELECTION: Seleccionar el borrador con mayor puntuación promedio de los Critics
4. FACT_CHECK: Fact-checker-1 y Fact-checker-2 en paralelo sobre el borrador seleccionado
5. STYLE: Style-1 y Style-2 en paralelo sobre el draft fact-checked
6. SEO: SEO Agent sobre el draft estilizado
7. FINAL: Editor Agent integra todos los feedbacks

## Criterio de avance
Un task solo pasa a la siguiente fase cuando TODOS los tasks de la fase actual tienen status=DONE.
Si un agente lleva más de 10 minutos sin actualizar su task: envía [PING] vía SendMessage.
Si no responde en 3 minutos adicionales: marca el task como BLOCKED y notifica al humano.

Paso 2: el ciclo de crítica entre agentes

La parte más importante del sistema es cómo los Critics reciben y procesan los borradores. El feedback no puede ser abierto: necesita estructura y categorías concretas para que el Editor Agent pueda interpretarlo y actuar sobre él sin ambigüedad.

# review_prompt.py

CRITIC_TEMPLATE = """Eres Critic-{critic_id}. Revisas el borrador de Writer-{writer_id}.

BORRADOR:
{draft_content}

CRITERIOS (puntúa cada sección del 1 al 5):
1. PRECISION_TECNICA: ¿Los conceptos están correctamente explicados? ¿Hay afirmaciones incorrectas?
2. ESTRUCTURA: ¿El flujo es lógico? ¿Faltan secciones importantes?
3. ACCESIBILIDAD: ¿Es comprensible para el público objetivo? ¿El nivel técnico es consistente?

INSTRUCCION: Responde SOLO en JSON con este schema exacto:
{{
  "writer_id": "{writer_id}",
  "critic_id": "{critic_id}",
  "scores": {{
    "precision_tecnica": ,
    "estructura": ,
    "accesibilidad": 
  }},
  "total": ,
  "bloqueantes": [],
  "sugerencias": [],
  "recomendacion": "APROBAR" | "REVISAR" | "RECHAZAR"
}}"""


def calculate_winner(critic_outputs: list[dict]) -> str:
    """Selecciona el writer_id con mayor total promedio."""
    scores_by_writer = {}
    for review in critic_outputs:
        wid = review["writer_id"]
        scores_by_writer.setdefault(wid, []).append(review["total"])

    return max(
        scores_by_writer,
        key=lambda wid: sum(scores_by_writer[wid]) / len(scores_by_writer[wid])
    )

El Boss Agent recoge los tres JSONs de los Critics, ejecuta calculate_winner y pasa el borrador ganador a la fase de Fact-check. Si dos borradores tienen puntuación idéntica, el Editor Agent recibe ambos y produce un merge: se le indica explícitamente cuál es la fortaleza de cada uno según los Critics.

Paso 3: persistir el estado entre sesiones

El problema con las sesiones de Claude Code es que tienen un límite de contexto que puede agotarse antes de que el pipeline complete todas las fases. La solución es persistir el estado en una base de datos externa que cualquier agente pueda leer al iniciar su sesión.

Para proyectos pequeños y medianos, SQLite es suficiente. No necesitas levantar infraestructura adicional. Para cargas más altas o acceso concurrente real, PostgreSQL con soporte de JSON resuelve los mismos problemas. El artículo sobre Spec-Driven Multi-Agente con spec-kit detalla cómo estructurar el contrato de datos entre agentes, lo cual aplica directamente aquí.

# state_tracker.py
import sqlite3
from datetime import datetime


def init_db(db_path: str = "pipeline_state.db") -> sqlite3.Connection:
    conn = sqlite3.connect(db_path)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS tasks (
            id        TEXT PRIMARY KEY,
            phase     TEXT NOT NULL,
            agent_id  TEXT NOT NULL,
            status    TEXT DEFAULT 'PENDING',  -- PENDING, IN_PROGRESS, DONE, BLOCKED
            input_ref TEXT,
            output_ref TEXT,
            created_at TEXT,
            updated_at TEXT
        )
    """)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS agent_outputs (
            task_id    TEXT,
            agent_id   TEXT,
            content    TEXT,
            scores_json TEXT,
            created_at TEXT
        )
    """)
    conn.commit()
    return conn


def update_task(conn: sqlite3.Connection, task_id: str, status: str, output_ref: str = None):
    conn.execute(
        "UPDATE tasks SET status=?, output_ref=?, updated_at=? WHERE id=?",
        (status, output_ref, datetime.utcnow().isoformat(), task_id)
    )
    conn.commit()


def get_phase_status(conn: sqlite3.Connection, phase: str) -> dict:
    cursor = conn.execute(
        "SELECT agent_id, status FROM tasks WHERE phase=?", (phase,)
    )
    return {row[0]: row[1] for row in cursor.fetchall()}

Cada agente lee su task al inicio de la sesión, actualiza el status a IN_PROGRESS en cuanto empieza, y marca DONE al terminar con el output_ref apuntando al archivo de output. El Boss Agent hace polling cada 60 segundos para verificar si puede avanzar de fase.

Paso 4: Telegram como panel de control

Ejecutar 13 agentes sin visibilidad es trabajar a ciegas. La integración con Telegram permite recibir alertas cuando un agente se bloquea y enviar comandos sin abrir una terminal. Un bot básico cubre los casos más críticos: notificación de bloqueo, confirmación de avance de fase y resumen del output ganador.

# telegram_notifier.py
import httpx
import os

TELEGRAM_TOKEN = os.environ["TELEGRAM_BOT_TOKEN"]
CHAT_ID = os.environ["TELEGRAM_CHAT_ID"]
API_BASE = f"https://api.telegram.org/bot{TELEGRAM_TOKEN}"


async def notify_blocked(agent_id: str, task_id: str, last_update: str) -> None:
    text = (
        f"[BLOCKED] {agent_id}\n"
        f"Task: {task_id}\n"
        f"Ultimo update: {last_update}\n"
        f"Acciones: /resume_{agent_id} o /skip_{task_id}"
    )
    async with httpx.AsyncClient() as client:
        await client.post(f"{API_BASE}/sendMessage", json={"chat_id": CHAT_ID, "text": text})


async def notify_phase_complete(phase: str, winner_id: str, score: float) -> None:
    text = (
        f"[FASE {phase} OK]\n"
        f"Borrador ganador: {winner_id} (score: {score:.1f}/5)\n"
        f"Siguiente fase: /approve o /restart_{phase}"
    )
    async with httpx.AsyncClient() as client:
        await client.post(f"{API_BASE}/sendMessage", json={"chat_id": CHAT_ID, "text": text})

Con este setup puedes aprobar el avance de fase desde el móvil o pausar el pipeline si ves que el Boss Agent tomó una decisión incorrecta en la selección de borrador. Para patrones de control remoto más elaborados, el artículo sobre skills con memoria persistente en OpenClaw tiene un ejemplo aplicable a esta arquitectura.

En Producción

Los costes son el factor limitante real. Con Opus para el Boss y el Editor (los roles de mayor razonamiento) y Sonnet para el resto, una pasada completa del pipeline consume entre 600.000 y 1.500.000 tokens dependiendo de la longitud del output. A precios de marzo 2026, eso equivale a entre 1,80€ y 4,50€ por pipeline completo.

Para contenido de alto valor, el ROI es claro frente al trabajo manual. Para contenido de baja frecuencia o baja complejidad, el agente único sigue siendo más eficiente. Si tienes dudas sobre el coste de tokens antes de lanzar el sistema completo, el artículo sobre control de tokens en Claude Code explica cómo monitorizar el consumo en tiempo real.

Hay consideraciones de escalabilidad relevantes: el overhead de coordinación crece con el número de agentes activos simultáneamente. La arquitectura de 13 agentes funciona mejor ejecutando 3 o 4 teammates en paralelo por fase que intentando lanzar los 13 a la vez. La documentación oficial de Agent Teams recomienda empezar con 3-5 teammates y escalar desde ahí.

Los agentes pueden quedarse en bucle consumiendo tokens sin producir valor si no hay límites explícitos. Configura un timeout de 15 minutos por task y un límite de tokens por agente como medidas mínimas. Sin estos dos controles, un pipeline de 13 agentes puede consumir el doble de tokens de lo esperado en fallos silenciosos.

Sobre modelos: usa Haiku para tareas mecánicas como el SEO Agent (estructura, conteo de keywords, metadatos) y reserva Opus únicamente para los roles que requieren razonamiento complejo: el Boss Agent y el Editor final. Ese ajuste puede reducir el coste por pipeline en un 30-40% sin impacto perceptible en la calidad del output.

Errores comunes y depuración

Error: Dos agentes escriben en el mismo archivo
Causa: Agent Teams no tiene file locking nativo. Si dos teammates tienen el mismo path en su output, el segundo sobreescribe al primero.
Solución: Asigna a cada agente un directorio de output exclusivo con su ID. El Editor Agent trabaja siempre sobre copias, nunca sobre los originales. Dos agentes nunca deben tener el mismo output_ref.

Error: Un Critic revisa el borrador del mismo Writer que lo produjo
Causa: El Boss Agent no especificó la asignación cruzada en el spawn prompt del Critic.
Solución: En el task de cada Critic incluye explícitamente: "Tu borrador asignado es writer-{N+1 mod 3}, NO writer-{N}". Valida en el Boss Agent que ningún Critic tiene asignado su propio Writer antes de lanzar la fase REVIEW.

Error: El pipeline se cuelga en la transición entre fases
Causa: Un agente terminó pero no actualizó el status en la DB, o lo actualizó con un valor fuera del enum esperado.
Solución: Añade validación de schema en el Boss Agent al leer el estado. Si el campo status no es uno de PENDING, IN_PROGRESS, DONE, BLOCKED, marca automáticamente como BLOCKED y notifica vía Telegram en lugar de esperar el timeout.

¿Cuánto cuesta realmente ejecutar 13 agentes en producción?

Con Opus para Boss y Editor y Sonnet para el resto, espera entre 1,80€ y 4,50€ por pipeline completo dependiendo de la longitud del output. Si usas Sonnet para todos los roles, el coste baja a 0,90€-2€ con algo menos de calidad en la síntesis final. Haiku para el SEO Agent ahorra tokens en tareas mecánicas sin impacto en calidad.

¿Puedo implementar revisión cruzada sin activar Agent Teams experimental?

Sí. Puedes usar subagentes clásicos en secuencia: lanzas el Writer, guardas el output en disco o DB, lanzas el Critic con ese output como input, y así sucesivamente. Pierdes la comunicación directa entre agentes y la auto-coordinación de la lista de tareas compartida, pero el patrón de revisión cruzada funciona igualmente. Los artículos sobre revisión cruzada con subagentes y auto-memory en Claude Code cubren las piezas complementarias para este enfoque secuencial.

¿Funciona este patrón solo para contenido o también para código?

El ciclo de crítica funciona para cualquier tarea que se beneficie de múltiples perspectivas: revisión de código con Critics especializados en seguridad, rendimiento y mantenibilidad como roles separados, análisis de datos, generación de informes técnicos. Para revisión de código, VS Code con Agent Mode ofrece una interfaz que simplifica parte de la orquestación descrita aquí.

Lo que cambia cuando el sistema revisa solo

El mayor cambio no es técnico, sino de responsabilidad. Con un agente único eres el revisor implícito de cada output. Con 13 agentes y un ciclo de crítica integrado, tu rol pasa a ser supervisar que el pipeline fluye correctamente, no que cada borrador sea preciso. Eso libera tiempo, pero exige que los prompts de los Critics y los criterios del Boss Agent estén muy bien definidos desde el principio.

El patrón falla cuando los criterios de revisión son vagos o cuando el Boss Agent no tiene reglas claras para decidir cuándo una fase está suficientemente bien para avanzar. La calidad del sistema depende más de la especificación de los roles que del número de agentes.

¿Has montado un equipo de agentes con revisión entre pares? Los patrones de asignación cruzada son el punto donde más divergen las implementaciones reales. Cuéntame tu arquitectura en los comentarios o en Twitter @sergiomarquezp_. El siguiente paso natural es añadir memoria persistente entre pipelines para que los Critics aprendan qué tipos de errores son más frecuentes y ajusten sus criterios de revisión automáticamente, pero eso merece un artículo propio.