Un solo agente con demasiadas herramientas se vuelve lento e impreciso. El patrón supervisor-trabajadores en LangGraph divide el problema entre agentes especializados coordinados por uno que decide a quién delegar.
Un agente con 20 herramientas distintas —búsqueda web, consulta a base de datos, generación de reportes, envío de correos— tiene dos problemas medibles: el modelo elige peor la herramienta correcta cuando el catálogo es grande, y el prompt de sistema se vuelve inmanejable. El patrón supervisor-trabajadores resuelve esto asignando subconjuntos pequeños de herramientas a agentes especializados, y delegando la decisión de "a quién le toca" a un nodo supervisor cuya única tarea es enrutar.
El supervisor típicamente usa salida estructurada (`with_structured_output` sobre un modelo Pydantic con un campo `Literal` restringido a los nombres válidos de los miembros) para garantizar que el enrutamiento sea siempre a un nodo existente, evitando que el modelo invente un destino.
Cada trabajador, tras actuar, regresa siempre al supervisor, que decide el siguiente paso. Este ciclo continúa hasta que el supervisor determina que la tarea está completa.
Las versiones recientes de LangGraph permiten que un nodo devuelva directamente un objeto `Command`, combinando la actualización de estado con la decisión de a qué nodo ir, sin necesitar una arista condicional separada:
Esto reduce el boilerplate de `add_conditional_edges` cuando la lógica de enrutamiento vive naturalmente dentro del propio nodo que decide.
Cuando un "trabajador" es en sí mismo un agente con su propio ciclo ReAct de herramientas, conviene construirlo como un `StateGraph` independiente y usarlo como nodo del grafo del supervisor mediante `.compile()`, que produce un `Runnable` compatible:
Esta composición jerárquica —grafos dentro de grafos— es la forma recomendada de escalar arquitecturas multi-agente sin que el grafo principal se vuelva ilegible: el supervisor no necesita saber que "investigador" internamente hace 4 llamadas a herramientas en un ciclo propio.
Si las tareas no requieren especialización real de herramientas o conocimiento, dividir en múltiples agentes añade latencia (cada salto por el supervisor es una llamada extra al modelo) y costo sin beneficio de calidad. En nuestra experiencia, el patrón se justifica quirúrgicamente cuando hay dominios claramente separables —por ejemplo, un agente que solo consulta bases de datos SQL y otro que solo redacta en lenguaje natural— y no como arquitectura por defecto para cualquier problema conversacional.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel