Phase 16 - Lesson 05

Patrón Supervisor / Orquestador-Trabajador

Un agente líder planifica y delega; los trabajadores especializados ejecutan en contextos paralelos y reportan de vuelta. Este es el patrón detrás del sistema de Investigación (Research) de Anthropic (Claude Opus 4 como líder, Sonnet 4 como subagentes), medido en +90.2% sobre el Opus 4 de agente único en evaluaciones de investigación internas. La publicación de ingeniería de Anthropic informa que el 80% de la varianza en BrowseComp se explica únicamente por el uso de tokens; los sistemas multiagente ganan en gran medida porque cada subagente obtiene una ventana de contexto nueva. Esta lección construye el patrón de supervisor a partir de las primitivas y cubre las lecciones de ingeniería de 2026 de los despliegues en producción.

Tipo: Aprender + Construir Lenguajes: Python (stdlib, threading) Prerrequisitos: Fase 16 · 04 (Modelo Primitivo) Tiempo: ~75 minutos

El Problema

La investigación es la tarea prototípica en la que fallan los sistemas de agente único. Preguntas: "¿qué cambió en los sistemas multiagente entre 2023 y 2026?" Un solo agente lee cinco artículos de manera secuencial, llena la mitad de su contexto con su texto y luego tiene que razonar sobre todos ellos juntos. Olvida el primer artículo para cuando llega al quinto. No puede paralelizar.

El patrón de supervisor corrige esto: un agente líder planifica la búsqueda, delega cada subpregunta a un trabajador y sintetiza. Cada trabajador obtiene su propia ventana de 200k tokens para una pregunta acotada. El líder nunca ve los artículos originales; solo los resúmenes de los trabajadores.

El sistema de Investigación en producción de Anthropic reporta +90.2% en evaluaciones de investigación internas frente a un solo Opus 4. La misma publicación señala que el 80% de la varianza de BrowseComp se explica únicamente por el uso de tokens. Un contexto limpio por subagente es el mecanismo principal.

Concepto

El patrón

                 ┌──────────────┐
                 │   Lead       │  plans, decomposes,
                 │  (Opus 4)    │  synthesizes
                 └──┬────┬───┬──┘
                    │    │   │
            ┌───────┘    │   └───────┐
            ▼            ▼           ▼
      ┌─────────┐  ┌─────────┐  ┌─────────┐
      │ Worker1 │  │ Worker2 │  │ Worker3 │
      │(Sonnet) │  │(Sonnet) │  │(Sonnet) │
      └─────────┘  └─────────┘  └─────────┘
         fresh       fresh        fresh
         context     context      context

El líder nunca lee los materiales originales. Los trabajadores nunca ven el trabajo de los demás hasta que el líder realiza la síntesis. Cada flecha es una entrega (handoff) con un artefacto acotado.

Por que gana

Tres mecanismos:

1. Contexto limpio por subagente. Un trabajador que explora "FIPA-ACL heritage" no carga con los 40k tokens que el líder gastó en la planificación. Obtiene una ventana de 200k tokens para una sola pregunta.
2. Especialización mediante prompt. El prompt del líder es "descomponer y sintetizar", no "investigar". El prompt de cada trabajador es acotado: "encontrar qué cambió en X". Los prompts enfocados producen resultados enfocados.
3. Paralelismo. Los trabajadores se ejecutan de forma concurrente. El tiempo de ejecución real (tiempo de reloj) es aproximadamente max(worker_times) + plan + synthesis, no sum(worker_times).

Lecciones de ingeniería (Anthropic 2025)

La publicación de Anthropic enumera varias lecciones de producción que siguen siendo relevantes en 2026:

• Escalar el esfuerzo a la complejidad de la consulta. Consultas simples: un agente, 3-10 llamadas a herramientas. Consultas complejas: más de 10 agentes. El líder debe estimar esto, no quien realiza la llamada.
• De lo general a lo particular. Descomponer primero en subpreguntas generales, luego generar más trabajadores por subpregunta si la respuesta requiere profundidad.
• Despliegues arcoíris (Rainbow deployments). Los agentes son de larga duración y con estado (stateful). El esquema tradicional azul-verde (blue-green) no funciona. Anthropic utiliza despliegues arcoíris: lanzamiento gradual de nuevas versiones mientras las antiguas se van retirando (draining).
• El uso de tokens predomina. El enfoque multiagente consume aproximadamente 15 veces más tokens que el de agente único. Solo ejecútelo cuando el valor de la tarea justifique el costo.

El giro de LangGraph

LangGraph originalmente incluía una biblioteca langgraph-supervisor con un asistente de alto nivel create_supervisor. En 2025, LangChain cambió su recomendación a implementar el patrón de supervisor directamente mediante llamadas a herramientas (tool-calling), porque las llamadas a herramientas brindan más control sobre lo que ve el supervisor (ingeniería de contexto). La biblioteca sigue funcionando; la documentación ahora recomienda el formato de llamada a herramientas.

Modos de fallo

• El líder alucina el plan. Si el líder genera subpreguntas que no descomponen la pregunta real, los trabajadores realizarán una investigación precisa en el objetivo equivocado.
• Los trabajadores exploran en exceso. Sin límites de alcance explícitos, los trabajadores se desvían de la subpregunta asignada y ensucian el paso de síntesis.
• Conflictos de síntesis. Dos trabajadores devuelven hechos contradictorios. El líder debe volver a preguntar (agregar una ronda) o señalar el desacuerdo explícitamente. Elegir silenciosamente una opción es el peor fallo: el usuario nunca se entera de que hubo un desacuerdo.

Cuándo el supervisor es la opción incorrecta

• Tareas secuenciales. Si el paso 2 requiere literalmente la salida del paso 1, el paralelismo no aporta nada. Utilice un pipeline (CrewAI Sequential, grafo lineal de LangGraph).
• Consultas simples. Un solo agente las maneja de manera más rápida y económica. Utilice la verificación de "escalar esfuerzo" del líder antes de generar trabajadores.
• Determinismo estrito. El supervisor utiliza una delegación seleccionada por LLM. Los grafos estáticos son mejores cuando la auditoría o la reproducción importan más que la adaptabilidad.

Constrúyalo

El archivo code/main.py implementa un supervisor de tres trabajadores paralelos usando threading. El líder descompone una consulta en subpreguntas, los trabajadores se ejecutan concurrentemente en cada subpregunta y el líder sintetiza. No se usan LLM reales; los trabajadores están programados para simular la obtención y el resumen.

Estructura clave:

• Lead.plan(query) divide una consulta en 3 subpreguntas.
• Worker.run(sub_q) devuelve un resumen simulado (podría ser cualquier agente que use herramientas en producción).
• Lead.run(query) inicia los trabajadores en hilos (threads), se une (join) y sintetiza.

Ejecute:

python3 code/main.py

La salida muestra el plan, los rastros paralelos de los trabajadores con marcas de tiempo de inicio y fin, y la síntesis final. Se pueden ver las ganancias en tiempo real (wall-clock): tres trabajadores de 0.3 segundos se ejecutan en aproximadamente 0.35 segundos, no en 0.9.

Úselo

El archivo outputs/skill-supervisor-designer.md toma una consulta del usuario y produce un diseño de patrón de supervisor: prompt del sistema del líder, roles de los trabajadores, reglas de descomposición de subpreguntas y la plantilla de síntesis. Utilice esto antes de construir un nuevo sistema de agentes orientado a la investigación.

Prepárelo para Producción

Lista de verificación antes de desplegar un patrón de supervisor:

• Emparejamiento de modelos. Líder en un modelo de nivel de razonamiento (clase Opus, clase o3). Trabajadores en un modelo más rápido y económico (Sonnet, o4-mini).
• Tiempo de espera (timeout) del trabajador. Cualquier trabajador que exceda el doble de la mediana del tiempo de ejecución es finalizado; el líder lo vuelve a generar con un alcance más acotado o continúa sin él.
• Límite de tokens por trabajador. Un límite estricto (por ejemplo, 10 veces la entrada de síntesis esperada) evita que un trabajador descontrolado agote el presupuesto.
• Observabilidad. Rastrear el plan del líder, las llamadas a herramientas de cada trabajador y la síntesis. Esta es la base para cualquier depuración posterior.
• Despliegue arcoíris (Rainbow). Los agentes de larga duración con estado necesitan una transición gradual de versiones, no un reemplazo en caliente (hot swap).

Ejercicios

1. Ejecute code/main.py, luego modifique al líder para generar 5 trabajadores en lugar de 3. Observe el efecto en el tiempo de ejecución real. ¿Con qué cantidad de trabajadores el costo de creación supera los ahorros del paralelismo en esta demostración?
2. Implemente un tiempo de espera para el trabajador: finalice cualquier trabajador que se ejecute durante más de 0.5 segundos y haga que el líder sintetice los resultados restantes. ¿Qué observabilidad necesita para saber que un trabajador fue interrumpido?
3. Agregue un paso de detección de conflictos a la síntesis del líder: si dos trabajadores devuelven respuestas contradictorias, el líder registra el desacuerdo en lugar de elegir una. ¿Cómo se detecta una contradicción sin llamar a un LLM?
4. Lea la publicación de ingeniería del sistema de Investigación de Anthropic. Enumere tres prácticas que esta demostración básica necesitaría adoptar para ejecutarse en producción.
5. Compare create_supervisor de LangGraph (legado) con la nueva recomendación de llamadas a herramientas (tool-calling). ¿Cuál le brinda un mejor control sobre lo que ve el supervisor? ¿Por qué Anthropic pasa explícitamente solo las subrespuestas y no el contexto bruto del trabajador a la síntesis?

Términos Clave

Lecturas Adicionales

• Anthropic engineering — How we built our multi-agent research system — la referencia de producción para el patrón de supervisor
• LangGraph workflows and agents — el supervisor de llamada a herramientas ahora es la forma recomendada
• LangGraph supervisor reference — el asistente legado, todavía utilizado en producción en 2026
• OpenAI cookbook — Orchestrating Agents: Routines and Handoffs — variante de supervisor basada en transferencias (handoff)