Phase 16 - Lesson 08

Especialización de Roles — Planificador, Crítico, Ejecutor, Verificador

La descomposición multiagente más común en 2026: un agente planifica, uno ejecuta, uno critica o verifica. MetaGPT (arXiv:2308.00352) formaliza esto como SOPs codificados en prompts de rol — Gerente de Producto, Arquitecto, Gerente de Proyecto, Ingeniero, Ingeniero de QA — siguiendo Code = SOP(Team). ChatDev (arXiv:2307.07924) encadena diseñador, programador, revisor, probador a través de una "cadena de chat" con "desalucinación comunicativa" (los agentes solicitan explícitamente detalles faltantes). El verificador es fundamental: Cemri et al. (MAST, arXiv:2503.13657) demuestran que cada fallo de multiagente puede rastrearse hasta una verificación ausente o rota. PwC reportó una ganancia de precisión de 7× (10% → 70%) a partir de bucles de validación estructurados en CrewAI.

Tipo: Aprender + Construir Idiomas: Python (stdlib) Prerrequisitos: Fase 16 · 04 (Modelo Primitivo), Fase 16 · 05 (Supervisor) Tiempo: ~60 minutos

Problema

Los sistemas multiagente genéricos producen resultados genéricos. Tres programadores en un chat grupal escriben tres variantes del mismo código mediocre. Puedes agregar más agentes, agregar más rondas y aun así no superar el umbral de calidad.

La solución no es tener más agentes, sino agentes diferentes. Asigna roles distintos. Dale al crítico herramientas que el planificador no tiene. Dale al verificador una suite de pruebas objetiva. Ahora el sistema tiene un desacuerdo interno con correcciones fundamentadas, en lugar de solo suposiciones en paralelo.

Concepto

Los cuatro roles canónicos

Planificador. Lee el objetivo, produce una lista de pasos o una especificación. Herramientas: recuperación de información, documentación. Resultado: plan estructurado.

Ejecutor. Lee un paso del plan a la vez, produce el artefacto. Herramientas: las herramientas de trabajo reales (compilador de código, shell, cliente de API). Resultado: el artefacto.

Crítico. Lee el resultado del ejecutor en relación con la intención del planificador. Herramientas: acceso de solo lectura al artefacto, análisis estático. Resultado: aceptar/rechazar con motivos.

Verificador. Lee el artefacto y ejecuta una verificación determinista. Herramientas: ejecutor de pruebas, verificador de tipos, validador de esquemas. Resultado: aprobado/reprobado con evidencia.

El crítico es subjetivo, obstinado y, a menudo, basado en LLM. El verificador es objetivo, determinista y, a menudo, basado en código. No son el mismo rol.

El patrón SOP de MetaGPT

MetaGPT (arXiv:2308.00352) codifica los SOP (procedimientos operativos estándar) de la ingeniería de software como prompts de rol:

Gerente de Producto escribe el PRD.
Arquitecto produce el diseño del sistema.
Gerente de Proyecto divide las tareas.
Ingeniero implementa.
Ingeniero de QA ejecuta pruebas.

Cada rol tiene un esquema estricto de entrada/salida. El prompt del rol define lo que el rol es y lo que debe producir. La formulación Code = SOP(Team) — los SOP deterministas convierten un equipo de LLM en un pipeline predecible.

Desalucinación comunicativa de ChatDev

ChatDev añade un paso clave: cuando un ejecutor necesita un detalle específico que no estaba en el plan, le pregunta explícitamente al diseñador antes de continuar. Esto evita el fallo clásico de los LLM de inventar el detalle de forma plausible.

Implementación: el prompt del rol incluye "cuando necesites información específica que no se te haya proporcionado, pregúntale al rol correspondiente por su nombre antes de producir un resultado".

Por que el verificador es lo más importante

Cemri et al. (MAST) rastrearon 1642 fallos de ejecución multiagente. El 21.3% fueron brechas de verificación: el sistema entregó una respuesta que nadie había comprobado. El 79% restante a menudo se remonta a "hubo una verificación que falló silenciosamente o que nunca se ejecutó". La verificación es el rol fundamental que sostiene el sistema.

PwC reportó (implementaciones de CrewAI, 2025) que agregar un bucle de validación estructurado mejoró la precisión del 10% al 70%. Una ganancia de 7× con un solo rol.

Crítico vs Verificador

Un crítico es un LLM que revisa un artefacto en cuanto a calidad. Subjetivo. Puede dejarse engañar por una prosa plausible.
Un verificador es un programa determinista que se ejecuta sobre el artefacto. Objetivo. Devuelve aprobado/reprobado con evidencia.

Usa ambos. El crítico detecta problemas de estilo que el verificador no puede articular. El verificador detecta errores que el crítico no puede ver porque solo aparecen en tiempo de ejecución.

El antipatrón

Cada rol en tu sistema es un LLM y el resultado de cada rol es "se ve bien". Modo de fallo clásico de MAST. Agrega al menos un verificador cuyo aprobado/reprobado se decida mediante código, no por un LLM.

Mapeos de frameworks

CrewAI — Agent(role, goal, backstory) es la superficie de especialización clásica.
LangGraph — los nodos pueden tener prompts especializados; las aristas impõem o pipeline. (Wait, let's say: las aristas imponen el pipeline)
AutoGen — ConversableAgents específicos de rol con nombres de una sola palabra en un GroupChat.
OpenAI Agents SDK — herramientas de transferencia (handoff) entre Agents especializados por rol.

Constrúyelo

code/main.py implementa un pipeline de 4 roles que construye una función de Python simple:

Planificador produce una especificación.
Ejecutor genera una cadena de código.
Crítico (simulado por LLM) señala problemas obvios.
Verificador ejecuta el código generado en un entorno seguro (exec) contra un caso de prueba.

La demostración se ejecuta dos veces: una en la que el ejecutor produce código correcto (tanto el crítico como el verificador aprueban) y otra en la que el ejecutor produce código fuera de la especificación (el crítico no detecta el error porque parece plausible, el verificador lo detecta porque la prueba falla).

Ejecuta:

python3 code/main.py

Úsalo

outputs/skill-role-designer.md recibe una tarea y produce la lista de roles (3-5 roles), el esquema de entrada/salida por rol y la comprobación del verificador. Usa esto antes de conectar agentes a un framework.

Envíalo (Ship It)

Checklist:

Al menos un verificador determinista. Nunca de tipo totalmente LLM.
Esquema de E/S explícito por rol. El planificador devuelve una especificación, no prosa; el ejecutor lee ese esquema.
Desalucinación comunicativa. El ejecutor debe preguntar al planificador cuando falte información; nunca debe inventarla.
Orden de crítico/verificador. Ejecuta primero el crítico (económico, detecta problemas de diseño) y luego el verificador (lento, detecta errores).
Presupuesto del bucle. Máximo 2 rondas de revisión crítico-ejecutor antes de escalar a un humano.

Ejercicios

Ejecuta code/main.py y observa cómo el verificador detecta el error que el crítico pasó por alto. Agrega una comprobación de análisis estático (contar ocurrencias de return) como un verificador adicional. ¿Qué detecta este análisis que la prueba en tiempo de ejecución no nota?
Agrega un 5.º rol: "analista de requisitos" que traduzca el deseo del usuario en una especificación lista para el planificador. ¿Qué solicitudes de desalucinación comunicativa deberían fluir hacia él?
Lee la Sección 3 de MetaGPT ("Agents"). Enumera el esquema de entrada/salida de cada uno de los 5 roles de MetaGPT.
Lee el diagrama de la cadena de chat de ChatDev (arXiv:2307.07924, Figura 3). Identifica en qué punto la desalucinación comunicativa rompe un bucle que de otro modo sería infinito.
La ganancia de precisión de 7× reportada por PwC provino de bucles de verificación. Plantea la hipótesis de tres tareas en las que agregar un verificador no ayudaría, es decir, donde la comprobación determinista de la exactitud sea imposible o prohibitivamente costosa.

Términos Clave

Término	Lo que la gente dice	Lo que realmente significa
Especialización de roles	"Diferentes agentes, diferentes tareas"	Prompts del sistema distintos y ajustados para los roles de planificador/ejecutor/crítico/verificador.
Patrón SOP	"Procedimento operativo estándar codificado"	El enfoque de MetaGPT: los esquemas de E/S estrictos por rol convierten a un equipo en un pipeline.
Desalucinación comunicativa	"Preguntar antes de inventar"	Patrón de ChatDev: el ejecutor le pregunta al planificador cuando falta un detalle, en lugar de inventar uno.
Crítico	"Revisor LLM"	Revisor subjetivo y obstinado. Detecta problemas de estilo. Puede ser engañado por una prosa plausible.
Verificador	"Verificación determinista"	Aprobado/reprobado basado en código. Ejecutor de pruebas, verificador de tipos, validador de esquemas. No puede ser engañado.
Brecha de verificación	"Nadie comprobó"	El 21.3% de los fallos de MAST. El resultado se envió sin una verificación que habría detectado el error.
Bucle de revisión	"El crítico lo devuelve"	El rechazo del crítico desencadena una nueva ejecución del ejecutor con retroalimentación. Requiere un presupuesto límite.
Antipatrón totalmente LLM	"Se ve bien"	Cada rol es un LLM, sin comprobación determinista. Fallo clásico de MAST.

Lecturas Adicionales

Hong et al. — MetaGPT: Meta Programming for Multi-Agent Collaboration — el artículo de referencia del patrón SOP como prompt de rol
Qian et al. — Communicative Agents for Software Development (ChatDev) — cadena de chat + desalucinación comunicativa
Cemri et al. — Why Do Multi-Agent LLM Systems Fail? — taxonomía MAST; las brechas de verificación representan el 21.3% de los fallos
CrewAI docs — Agent roles — superficie de especificación de roles en producción