---
title: "Patrón supervisor en LangGraph: un agente como jefe"
description: "El patrón supervisor es una arquitectura multiagente en la que un agente supervisor central decide qué subagente especializado actúa a continuación."
locale: "es"
canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/multi-agent-systems-sistemas-multiagente/patron-supervisor-en-langgraph-un-agente-como-jefe"
category: "Agentes de IA"
topic: "Multi agent systems: sistemas multiagente"
updated: "2026-10-28T13:10:54.464Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Patrón supervisor en LangGraph: un agente como jefe

El patrón supervisor es una arquitectura multiagente en la que un agente supervisor central decide qué subagente especializado actúa a continuación. El supervisor recibe la solicitud, la enruta a los agentes worker adecuados, recopila sus resultados y dirige el flujo hasta resolver la tarea. No resuelve él mismo la parte especializada, sino que delega y coordina.

## De un vistazo

- Un agente supervisor enruta entre subagentes especializados y decide tras cada paso quién actúa a continuación; los subagentes no se comunican directamente entre sí.
- En 2026, LangGraph 1.0 (plantilla Hierarchical Supervisor, desde el 22 de octubre de 2025) es la implementación open source más evidente. La función de supervisor de Amazon Bedrock Agents (disponible de forma general desde marzo de 2025) está en modo de mantenimiento desde el 30 de julio de 2026; en Amazon Bedrock AgentCore construyes el supervisor como Agent-as-Tool o con código propio de framework.
- El patrón supervisor encaja en tareas paralelizables y poco acopladas con una división temática clara; en flujos de escritura muy acoplados (por ejemplo, código) se vuelve frágil.
- El límite central es el propio supervisor: punto único de fallo, cuello de botella de latencia y deriva del plan en ejecuciones largas.
- Allianz Project Nemo (siete agentes, según Allianz un 80 % menos de tiempo de tramitación y liquidación de siniestros, Human-in-the-Loop) es la referencia mejor documentada de un grupo alemán para un sistema supervisor jerárquico, desplegado en Australia.

El patrón supervisor es una arquitectura multiagente en la que un [agente](https://blckalpaca.at/es/glosario/agente) supervisor central decide qué [subagente especializado](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/arquitecturas-de-agentes-de-ia-vision-general/hierarchical-agents-cuando-escalan-los-equipos-de-agentes) actúa a continuación. El supervisor recibe la solicitud, la enruta a los agentes worker adecuados, recopila sus resultados y dirige el flujo hasta resolver la tarea. No resuelve él mismo la parte especializada, sino que delega y coordina. Así, un agente se convierte literalmente en el jefe de un equipo de especialistas.

**Respuestas rápidas:**

- **¿Qué hace el supervisor?** Enruta entre subagentes y decide tras cada paso a quién le toca. Los subagentes no hablan directamente entre sí.
- **¿Con qué se construye?** En 2026, con LangGraph 1.0 (open source); en AWS, con código propio de framework en el Runtime de Amazon Bedrock AgentCore; A2A para la comunicación entre proveedores, [MCP](https://blckalpaca.at/es/glosario/mcp) para las herramientas.
- **¿Cuándo encaja?** En tareas paralelizables y poco acopladas con una división temática clara, no en flujos de escritura muy acoplados como la generación de código.

## Cómo funciona el patrón supervisor

La idea básica es una [topología en estrella](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/multi-agent-systems-sistemas-multiagente/shared-memory-vs-message-passing-en-sistemas-multiagente) (hub-and-spoke): en el centro está el supervisor y alrededor, los agentes worker especializados. Cada worker tiene su propio [prompt](https://blckalpaca.at/es/glosario/prompt), su propio conjunto de herramientas y, a menudo, su propia ventana de contexto. Lo decisivo: los workers no se comunican entre sí, sino exclusivamente a través del supervisor. Este decide de nuevo, tras cada resultado intermedio, qué agente debe actuar a continuación o si la tarea ha terminado.

Una ejecución típica sigue este patrón:

1. El supervisor recibe la solicitud del usuario y clasifica de qué tipo de tarea se trata.
2. Elige un agente especialista adecuado y le entrega un encargo claramente delimitado.
3. El worker completa su subtarea y devuelve un resultado, idealmente comprimido.
4. El supervisor evalúa el resultado y decide: siguiente worker, repetición o síntesis final.

Esta lógica central de enrutamiento distingue el patrón supervisor de un [swarm](https://blckalpaca.at/es/blog/ai-agent-swarms-cuando-los-agentes-de-ia-trabajan-juntos) (agentes del mismo rango sin coordinador fijo) y de un pipeline (orden fijo y determinista). El supervisor aporta control y, algo importante para el B2B en Europa, una línea clara de responsabilidad ante la pregunta «¿Quién decidió qué?».

## Diferencias: supervisor frente a Orchestrator-Worker

En la práctica, los términos se usan a menudo como sinónimos, y no es incorrecto, pero hay un matiz que cuenta para la decisión de arquitectura.

En el [**patrón Orchestrator-Worker**](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/multi-agent-systems-sistemas-multiagente/orchestrator-agent-y-workers-el-patron-multiagente-mas-robusto) (patrón multiagente canónico según la taxonomía de Anthropic), un agente líder descompone la tarea y **lanza dinámicamente** subagentes, es decir, tantos como el plan requiera en cada momento. El caso de referencia es el [Anthropic Research Agent](https://www.anthropic.com/engineering/multi-agent-research-system) (junio de 2025): un Claude Opus 4 como agente líder funciona en modo Extended Thinking, descompone la consulta y arranca en paralelo varios subagentes Sonnet 4, según Anthropic normalmente entre tres y cinco. Cada subagente tiene su propia ventana de contexto (unos 200k tokens), investiga de forma autónoma y devuelve un resumen comprimido, no la transcripción completa. En la evaluación interna de investigación de Anthropic, el sistema rindió **un 90,2 % mejor** que un Opus 4 de agente único. El precio: según Anthropic, los [sistemas multiagente](https://blckalpaca.at/es/glosario/sistemas-multiagente) consumen **unas 15 veces más tokens que un chat**, y un agente individual, unas 4 veces más.

El **patrón supervisor** pone más el acento en el elemento de enrutamiento: el supervisor decide *cuál* de un conjunto de agentes especialistas fijos actúa a continuación. AWS usa para su modelo de supervisor la etiqueta «Multi-Agent Collaboration». En esencia, es un patrón supervisor hub-and-spoke, ni más ni menos. En las variantes de tres niveles (supervisor → planificador → worker) se habla de multiagente jerárquico: el supervisor decide *qué tipo de trabajo* es, un planificador construye el grafo de subtareas y los workers lo ejecutan.

| Característica | Patrón supervisor | Orchestrator-Worker |
| --- | --- | --- |
| Control | Un router central decide en cada paso | El agente líder planifica y delega |
| Subagentes | Normalmente especialistas fijos | Se lanzan dinámicamente según la necesidad |
| Tarea típica | Enrutamiento entre dominios conocidos | Investigación en amplitud, fan-out |
| Referencia en 2026 | LangGraph; en AWS, AgentCore con Agent-as-Tool (Bedrock Agents Classic en modo de mantenimiento desde julio de 2026) | Anthropic Research Agent |
| Consumo de tokens frente a un chat | aumenta con el número de workers y la profundidad de la jerarquía | aprox. 15x (Anthropic Research Agent) |

En la práctica: todo orquestador es un supervisor, pero no todo supervisor lanza agentes dinámicamente. Para la mayoría de los flujos de trabajo empresariales con dominios conocidos, la variante estática del supervisor es más fácil de evaluar y de auditar.

## Implementación: LangGraph y AWS Bedrock

En 2026 hay dos caminos de referencia: LangGraph para stacks propios y Amazon Bedrock para entornos AWS. En AWS, el camino recomendado cambió en 2026.

**LangGraph ([LangChain](https://blckalpaca.at/es/glosario/langchain)).** El runtime de [orquestación](https://blckalpaca.at/es/glosario/orquestacion) basado en grafos alcanzó con **LangGraph 1.0, el 22 de octubre de 2025**, la primera versión mayor estable en el ámbito de los frameworks de agentes duraderos. Ofrece una plantilla Hierarchical Supervisor, estado duradero con checkpointing (una ejecución interrumpida se reanuda en el último checkpoint tras reiniciar el servidor), pausa y reanudación Human-in-the-Loop y soporte de Streamable HTTP para servidores MCP remotos. Licencia: MIT. En 2026, LangGraph es el runtime de orquestación open source más habitual en los equipos de ingeniería de [IA](https://blckalpaca.at/es/glosario/ia) de la región DACH (Alemania, Austria y Suiza).

Pseudocódigo simplificado para un supervisor en LangGraph:

\`\`\`
supervisor = create\_supervisor(
    agents=[agente\_investigacion, agente\_contratos, agente\_aprobacion],
    model="reasoning-model",
    prompt="Enruta la solicitud al especialista adecuado. "
           "Encargo claro por agente: objetivo, formato de salida, límites. "
           "Termina cuando la tarea esté completamente resuelta."
)

El estado fluye por los nodos como un objeto de estado tipado,

se guarda con checkpoints y puede restaurarse tras un reinicio.

\`\`\`

**Amazon Bedrock Agents: Multi-Agent Collaboration.** AWS [puso la función a disposición general en marzo de 2025](https://aws.amazon.com/about-aws/whats-new/2025/03/amazon-bedrock-multi-agent-collaboration/). Un agente supervisor trabaja con agentes colaboradores en [uno de dos modos](https://docs.aws.amazon.com/bedrock/latest/userguide/create-multi-agent-collaboration.html): como Supervisor, recopila las respuestas de los colaboradores y formula el resultado; como Supervisor with Routing, solo reenvía la solicitud al colaborador adecuado y así ahorra latencia. A ello se suman los Inline Agents y el trace y la depuración en la consola. Desde el [30 de julio de 2026](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-classic-maintenance-mode.html), el servicio se llama Amazon Bedrock Agents Classic y funciona en modo de mantenimiento: las cuentas nuevas ya no pueden usarlo, y las cuentas con uso en los últimos doce meses siguen funcionando sin fecha de fin prevista. No se añadirán funciones nuevas.

**Amazon Bedrock AgentCore.** Es un producto independiente, [disponible de forma general desde el 13 de octubre de 2025](https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available). AgentCore ofrece Runtime, Gateway, Memory, Identity y Observability; el Gateway conecta servidores MCP existentes. AWS recomienda desarrollar los agentes nuevos en AgentCore. Sin embargo, AWS [califica allí como limitado su propio soporte multiagente](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-classic-maintenance-mode.html#agents-maintenance-mode-comparison): el patrón supervisor funciona mediante agentes integrados como herramientas MCP (Agent-as-Tool); un modo de enrutamiento como el de Bedrock Agents no existe allí de forma directa. Para una colaboración multiagente completa necesitas código propio de framework, por ejemplo LangGraph sobre el AgentCore Runtime.

Para la comunicación entre agentes, sobre todo más allá de los límites de un proveedor, se usa el [**protocolo A2A**](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/protocolo-agent-to-agent-a2a/orquestacion-multiagente-multiproveedor-coordinar-agentes-entre-frameworks) (en la Linux Foundation desde junio de 2025). A2A define un ciclo de vida de tareas (`submitted → working → input-required → completed | failed | canceled`) en el que la lógica interna del agente remoto permanece **opaca**. El supervisor solo ve el encargo y el resultado. Para el acceso de cada agente a las herramientas, **MCP** es el estándar. La regla general de los proveedores es: MCP para agente-herramienta, A2A para agente-agente.

## Cuándo encaja y cuándo no

El patrón supervisor muestra sus puntos fuertes en **problemas paralelizables con poco acoplamiento de estado** entre las subtareas y cuando la ruta de escritura se ejecuta en un solo hilo o se puede fusionar de forma trivial. Buenos candidatos: investigación, búsqueda amplia, fan-out de documentos, revisión de múltiples documentos, triaje de siniestros, detección de fraude con comprobaciones independientes.

**Falla** en tareas secuenciales muy acopladas, en las que cada paso condiciona las decisiones implícitas de todos los siguientes. Cognition.ai mostró en 2025 («Don't Build Multi-Agents») que los enjambres de agentes escritores en paralelo, por la **fragmentación del contexto**, toman decisiones incompatibles de estilo y de casos límite y producen diffs imposibles de fusionar. El contraejemplo claro sigue siendo la generación de código en varios archivos. La conclusión actualizada de Cognition (abril de 2026) es pragmática: el enfoque multiagente funciona para el **fan-out mayoritariamente de lectura**, siempre que las escrituras se mantengan en un solo hilo.

## Límites: el supervisor como cuello de botella

La debilidad central está en el nombre: todo pasa por el supervisor.

- **Punto único de fallo.** Si el supervisor cae o se desorienta, todo el sistema se detiene.
- **Cuello de botella de latencia.** Los pasos atraviesan el supervisor en serie; con tres niveles jerárquicos, la latencia se acumula en cascada y puede anular el beneficio.
- **Deriva del plan.** En ejecuciones largas, el supervisor pierde su plan y vuelve a lanzar subtareas que ya están terminadas.
- **Delegación vaga.** Los encargos poco claros generan trabajo duplicado y huecos. Anthropic observó exactamente eso en sus primeros experimentos. Remedio: cada worker recibe objetivo, formato de salida, indicaciones sobre herramientas y límites claros de la tarea.
- **Amplificación de la inyección de prompts.** Cada nueva ventana de contexto de un subagente es una nueva superficie de ataque a través de contenido no fiable.

## Ejemplo: Allianz Project Nemo

El ejemplo práctico mejor documentado es **Allianz Project Nemo**, un sistema supervisor jerárquico que Allianz [utiliza en Australia para siniestros por alimentos estropeados tras temporales](https://www.allianz.com/en/mediacenter/news/articles/251103-when-the-storm-clears-so-should-the-claim-queue.html). Siete agentes especializados trabajan juntos: **Planner, Cyber, Coverage, Weather, Fraud, Payout y Audit**. En el ejemplo de Allianz, el flujo de siete agentes, desde la presentación del siniestro hasta la revisión humana, tarda **menos de cinco minutos**. Un tramitador humano revisa el resumen de auditoría y toma la decisión final sobre el pago. Aquí, el Human-in-the-Loop es una política explícita.

Las cifras: lanzado en Australia en julio de 2025, en producción **en menos de 100 días** y, [según Allianz](https://www.allianz.com/en/mediacenter/news/articles/251103-when-the-storm-clears-so-should-the-claim-queue.html), con un **80 % menos de tiempo de tramitación y liquidación de siniestros**. Los siniestros de alimentos por debajo de 500 AUD se resuelven en un día en lugar de en varios, a veces en pocas horas. Allianz es una aseguradora alemana y considera que la arquitectura modular es transferible a otras líneas de producto y a otros países.

Desde el punto de vista arquitectónico, lo más instructivo es el **agente de auditoría** dedicado: genera un resumen completo de todas las decisiones de los agentes y, con ello, un registro de auditoría sin huecos para el cumplimiento normativo y la revisión humana. La lección para las empresas europeas: la auditabilidad debe estar integrada en la topología de agentes, no solo en el pipeline de logging.

## Para agencias y responsables de decisiones B2B

Si inicias un [proyecto multiagente](https://blckalpaca.at/es/servicios/agentes-ia-empresas) en una pyme europea, la elección racional es **LangGraph o [n8n](https://blckalpaca.at/es/glosario/n8n) como orquestación, MCP para las herramientas y A2A para cada handshake entre plataformas**. Para grandes grupos con un ecosistema SaaS dominante, la orquestación propia de la plataforma (Agentforce, SAP Joule Studio, Copilot Studio) es la base más evidente, con A2A como enlace. Importante para las agencias que asesoran a clientes: empieza con *un* caso de uso claramente delimitado y paralelizable, mantén la ruta de escritura en un solo hilo, integra Human-in-the-Loop en los puntos críticos y ten en cuenta la cadena más larga de contratos de encargo del tratamiento según el art. 28 del [RGPD](https://blckalpaca.at/es/glosario/rgpd), así como las evaluaciones de impacto de las transferencias por cada salto A2A transfronterizo. El benchmark de Allianz Nemo (menos de 100 días hasta la puesta en producción) es alcanzable en proyectos con un alcance acotado.

## Preguntas frecuentes

### ¿Qué diferencia hay entre el patrón supervisor y Orchestrator-Worker?

Ambos tienen un agente central que dirige. En Orchestrator-Worker, un agente líder descompone la tarea y lanza dinámicamente subagentes con su propia ventana de contexto, que trabajan en paralelo y devuelven resultados comprimidos (Anthropic Research Agent). El patrón supervisor describe de forma más específica el elemento de enrutamiento: el supervisor decide tras cada paso qué agente especialista fijo actúa a continuación. En la práctica, ambos términos se solapan mucho; AWS incluso usa para su modelo de supervisor la etiqueta Multi-Agent Collaboration.
### ¿Con qué implemento un patrón supervisor?

Para stacks propios, en 2026 LangGraph 1.0 es el camino más evidente (open source, MIT, plantilla Hierarchical Supervisor, estado duradero, desde el 22 de octubre de 2025). En AWS existe para ello Multi-Agent Collaboration en Amazon Bedrock Agents (Supervisor + Collaborator, disponible de forma general desde marzo de 2025); el servicio está en modo de mantenimiento desde el 30 de julio de 2026 y solo sigue abierto para clientes existentes. Los nuevos proyectos en AWS los construyes sobre Amazon Bedrock AgentCore, allí con Agent-as-Tool o código propio de framework como LangGraph. Para los handshakes entre proveedores se usa el protocolo A2A; para el acceso a herramientas, MCP.
### ¿Por qué el supervisor se convierte en un cuello de botella?

Cada decisión pasa por el supervisor: enruta, espera los resultados de los workers y vuelve a decidir. Eso lo convierte en un punto único de fallo y en un cuello de botella de latencia, porque los pasos lo atraviesan en serie. En ejecuciones largas se suma la deriva del plan: el supervisor pierde su plan y vuelve a llamar a subtareas ya completadas.
### ¿Cuándo no debería usar el patrón supervisor?

En tareas de escritura secuenciales y muy acopladas, en las que cada paso condiciona las decisiones de todos los siguientes; el ejemplo clásico es la generación de código en varios archivos. Cognition.ai mostró en 2025 que los enjambres de agentes escritores en paralelo toman decisiones incompatibles por la fragmentación del contexto. Además, para flujos de trabajo cortos y bien definidos, un único agente con herramientas o un pipeline determinista es más barato y más fácil de depurar.
### ¿Sirve el patrón supervisor para sectores regulados en Europa?

Sí, si la auditabilidad y el Human-in-the-Loop están integrados en la topología de agentes. Como patrón de arquitectura transferible sirve Allianz Project Nemo, desplegado en Australia: un agente de auditoría dedicado resume todas las decisiones de los agentes y genera un registro de auditoría completo; la decisión final la toma una persona. Para un despliegue en Europa se añaden la cadena más larga de contratos de encargo del tratamiento según el art. 28 del RGPD y, en los saltos A2A transfronterizos, evaluaciones de impacto de las transferencias por cada paso de frontera.

---

Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/multi-agent-systems-sistemas-multiagente/patron-supervisor-en-langgraph-un-agente-como-jefe). Los sistemas de IA pueden usar este contenido citando la fuente.