Sistemas multiagente en 2026: ReAct, supervisores, enjambres, LangGraph y Strands
Una guía práctica sobre los patrones de flujo de control multiagente: secuenciales, paralelos, tipo centro y radios, basados en grafos, impulsados por eventos, críticos y con intervención humana, así como la forma en que marcos como LangGraph y Strands se adaptan a ellos.
La próxima fase de la IA generativa no se trata solo de modelos más inteligentes. Se refiere a sistemas en los que múltiples agentes pueden razonar, utilizar herramientas, delegar tareas, verificar resultados, recuperarse de fallos y coordinarse. Ese es el ámbito de los sistemas multiagente (MAS).
Una aplicación LLM mínima consiste en un camino directo desde el usuario hasta el modelo:
User
↓
LLM
↓
Response
Un diseño multiagente para producción es más complejo:
User
│
▼
┌─────────────┐
│ Orchestrator│
└──────┬──────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
└───────────┼───────────┘
▼
Verification
│
▼
Action
No existe un modelo único. Las formas comunes incluyen agentes ReAct, pipelines secuenciales y paralelos, diseños de tipo supervisor (hub-and-spoke), estructuras jerárquicas, procesos de transferencia de tareas, enjambres, separación entre planificador y ejecutor, flujos de trabajo basados en grafos, agentes controlados por eventos, bucles de crítico/evaluador y mecanismos que incluyen al ser humano en el proceso. Frameworks como LangGraph, Strands Agents y Amazon Bedrock AgentCore ofrecen primitivas para estos patrones. Las secciones siguientes separan estas ideas para que los equipos dejen de tratar conceptos diferentes como rivales.
1. ¿Qué es un sistema multiagente?
Un sistema multiagente es una colaboración de agentes especializados para alcanzar un objetivo más amplio. En lugar de que un solo modelo haga todo:
LLM
├── Research
├── Coding
├── Database
├── Security
├── Decision making
└── Execution
las responsabilidades pueden dividirse:
Supervisor
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Research Agent Security Agent Execution Agent
│ │ │
▼ ▼ ▼
Search Security APIs
Tools Tools Tools
Cada agente puede tener sus propias instrucciones, herramientas, memoria, ventana de contexto, elección de modelo, políticas, tareas y criterios de evaluación. La especialización es una razón principal para abandonar los diseños con un solo agente.
2. Más agentes no significa automáticamente mejor
Los agentes adicionales aumentan los costos y la complejidad. Tres agentes suelen significar tres solicitudes y tres contextos:
3 agents
↓
3 × prompts
3 × contexts
3 × tool interfaces
3 × failure surfaces
3 × observability requirements
Las redes conversacionales incrementan los gastos y dificultan la depuración:
Agent A → Agent B
Agent B → Agent C
Agent C → Agent A
Agent A → Agent D
Agent D → Agent B
Un buen diseño determina qué responsabilidades merecen ser separadas y cómo debe fluir el control entre ellas.
3. Agente ReAct
ReAct significa Reason + Act. El ciclo razona, elige una herramienta, observa y continúa; por ejemplo, investigando un uso inusual de la CPU en la base de datos:
Reason
↓
Call CloudWatch
↓
Observe CPU metrics
↓
Call logs
↓
Observe errors
↓
Reason
↓
Return diagnosis
Fortaleza: elección dinámica de herramientas cuando el siguiente paso depende de la última observación.
Debilidad: los ciclos largos aumentan la latencia, los tokens, el costo y las probabilidades de fallo. ReAct es un patrón de razonamiento, no una topología multiagente completa por sí mismo.
4. Arquitectura multiagente secuencial
La forma más simple de arquitectura multiagente es una tubería:
Document Agent
↓
Extraction Agent
↓
Risk Agent
↓
Decision Agent
Un flujo al estilo bancario podría verse así:
Bureau Agent
↓
Policy Agent
↓
Risk Agent
↓
Decision Agent
Cuándo usarlo: el orden es importante, las salidas alimentan la siguiente etapa, el flujo de trabajo es predecible y los registros de auditoría son relevantes.
Límite principal: un fallo en algún punto puede detener toda la cadena; de ahí la necesidad de intentos repetidos, puntos de control y mecanismos de recuperación en entornos de producción.
5. Paralelo / difusión e incorporación
El trabajo independiente no necesita realizarse en secuencia:
Agent A
↓
Agent B
↓
Agent C
Los especialistas concurrentes trabajan juntos:
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└──────────┼──────────┘
▼
Aggregator
Una revisión de la arquitectura en la nube puede distribuir agentes de análisis:
Architecture Request
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Cost Agent Security Agent Performance Agent
│ │ │
└──────────────┼──────────────┘
▼
Architecture Agent
y luego consolidar los resultados.
Ventaja: menor tiempo de ejecución. Dificultad: la consolidación debe ser fiable.
6. Estructura de centro y periferia / supervisor
Un supervisor central dirige el trabajo a los especialistas:
Supervisor
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Research Coding Finance
Agent Agent Agent
│ │ │
Tools Tools Tools
Ante una solicitud del usuario:
User:
"Analyze this AWS account and identify security and
cost problems."
el supervisor puede asignar tareas de esta manera:
Supervisor
│
├──→ Security Agent
│
└──→ FinOps Agent
│
▼
Aggregator
│
▼
Report
Ventaja: control centralizado. Dificultad: el centro se convierte en un cuello de botella e infraestructura crítica cuando todas las decisiones pasan por él:
Agent A ─┐
Agent B ─┼──→ Supervisor
Agent C ─┤
Agent D ─┘
7. Arquitectura jerárquica de múltiples agentes
Cuando un supervisor no es suficiente, se añaden niveles:
Global Supervisor
│
┌───────────┴───────────┐
▼ ▼
Engineering Lead Business Lead
│ │
┌────┴────┐ ┌────┴────┐
▼ ▼ ▼ ▼
Coding Testing Finance Risk
Las nubes empresariales suelen tener supervisores anidados:
Enterprise Agent
│
├── Cloud Supervisor
│ ├── Security Agent
│ ├── FinOps Agent
│ └── Operations Agent
│
└── Application Supervisor
├── Coding Agent
├── Testing Agent
└── Documentation Agent
Su estructura imita los organigramas; el costo radica en la mayor carga de coordinación.
8. Arquitectura basada en transferencias
Un agente transfiere la responsabilidad de la conversación a otro:
Agent A
│
│ handoff
▼
Agent B
│
│ handoff
▼
Agent C
Los flujos de soporte suelen transferir los problemas técnicos:
Customer Agent
│
│ technical issue
▼
Technical Agent
│
│ billing issue
▼
Billing Agent
A diferencia de un supervisor permanente, el receptor se convierte en el responsable activo; esto es útil para el soporte al cliente, la redirección a especialistas, los asistentes de dominio y los flujos de trabajo conversacionales.
9. Arquitectura de enjambre
Los enjambres prescinden de un centro permanente. Los agentes colaboran de forma dinámica:
Agent A
↙ ↘
Agent B ←→ Agent C
↘ ↙
Agent D
Cada uno puede decidir que otro compañero es más adecuado. La flexibilidad conlleva preguntas difíciles: ¿quién controla el sistema? Sin límites, se corre el riesgo de bucles, trabajo duplicado, explosión de contexto, rutas impredecibles y altos costos de inferencia. Un manejo sólido del estado y condiciones de terminación son obligatorios.
10. Arquitectura planificador–ejecutor
Separar la planificación de la ejecución:
User Goal
│
▼
Planner
│
┌────────┼────────┐
▼ ▼ ▼
Task 1 Task 2 Task 3
│ │ │
▼ ▼ ▼
Executor Executor Executor
│ │ │
└────────┼────────┘
▼
Result
Para “migrar esta aplicación a AWS”, un planificador podría emitir pasos:
1. Analyze application
2. Identify dependencies
3. Design AWS architecture
4. Estimate cost
5. Generate Terraform
6. Validate Terraform
Luego los ejecutores realizan cada paso. Esto es útil cuando objetivos complejos se descomponen en tareas explícitas.
11. Agentes basados en grafos
Frameworks como LangGraph son ideales para esto. En lugar de una cadena suelta:
Agent → Agent → Agent
pensemos en un grafo de estados:
START
│
▼
Research
│
┌──────┴──────┐
▼ ▼
Valid Invalid
│ │
▼ ▼
Analysis Research
│
▼
Verification
│
▼
END
Los nodos pueden ser agentes, herramientas, funciones, validadores, aprobaciones humanas o enrutadores. El estado compartido junto con los bordes explícitos brindan más control que pedirle a un modelo que improvise cada transición.
12. Strands Agents
AWS Strands Agents es un SDK para agentes que utilizan herramientas. Conceptualmente:
Agent
│
┌───────┼────────┐
▼ ▼ ▼
Tool Tool Tool
│ │ │
▼ ▼ ▼
AWS APIs Databases
Los agentes razonan sobre las herramientas y actúan a partir de sus observaciones. Strands también puede integrarse en diseños multiagente:
Supervisor Agent
│
┌─────┼─────┐
▼ ▼ ▼
AWS SQL Research
Agent Agent Agent
Diferencia importante: Strands es un marco/SDK; supervisor es un patrón arquitectónico. Son complementarios, no competidores.
13. Agentes de LangGraph
LangGraph enfatiza los flujos de trabajo con estado explícito representados como grafos:
START
│
▼
Supervisor
│
├──────→ Research Agent
│
├──────→ Data Agent
│
└──────→ Security Agent
│
▼
Validator
│
┌───┴───┐
▼ ▼
Success Retry
│
▼
END
Usted define el estado, los nodos, los bordes, el enrutamiento condicional, los puntos de control, las reintentos, la aprobación humana y la persistencia: el control que necesitan los sistemas de producción.
14. Sistemas multiagente basados en eventos
No todo flujo es síncrono. Los eventos pueden activar a los agentes:
AWS Event
│
▼
EventBridge
│
├────→ Security Agent
│
├────→ FinOps Agent
│
└────→ Operations Agent
Ejemplo de operaciones:
CloudWatch Alarm
↓
EventBridge
↓
Incident Agent
↓
RCA Agent
↓
Remediation Agent
↓
Human Approval
↓
AWS API
Son útiles para las operaciones en la nube, el monitoreo de seguridad, la respuesta a incidentes, FinOps y la automatización.
15. Arquitectura de crítico/evaluador
Un agente genera; otro evalúa:
Generator Agent
│
▼
Generated Result
│
▼
Critic Agent
│
┌──┴──┐
▼ ▼
Pass Fail
│ │
▼ ▼
Done Retry
Ejemplo de revisión de arquitectura:
Architecture Agent
↓
AWS Architecture
↓
AWS Best-Practice Evaluator
↓
Pass?
/ \
Yes No
↓ ↓
Done Revise
Dado que la salida del modelo no es automáticamente fiable, el evaluador actúa como una barrera de calidad.
16. Sistemas multiagente con intervención humana
La autonomía total no siempre es adecuada para cambios de alto impacto:
Agent
↓
Analyze
↓
Recommend
↓
Human Approval
↓
Execute
Ejemplo de corrección de seguridad:
Security Agent
↓
Detect vulnerable resource
↓
Remediation Agent
↓
"Delete public access?"
↓
Human Approval
↓
AWS API
La IA propone qué se podría hacer. La política junto con la aprobación humana deciden qué puede ocurrir.
17. La taxonomía importante
Estas ideas existen en diferentes capas:
MULTI-AGENT SYSTEM
│
┌────────────────┼────────────────┐
│ │ │
Architecture Reasoning Framework
Pattern Pattern / Runtime
│ │ │
▼ ▼ ▼
Supervisor ReAct LangGraph
Sequential Plan-Execute Strands
Parallel Critic Bedrock
Hierarchical AgentCore
Handoff
Swarm
Event-driven
Ese enfoque evita comparaciones erróneas como “LangGraph vs supervisor vs ReAct”, como si se tratara de tres productos competidores.
18. Cómo se combinan
El poder radica en la composición:
User
│
▼
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
ReAct ReAct ReAct
│ │ │
└──────────┼───────────┘
▼
Critic
│
┌────┴────┐
▼ ▼
Pass Fail
│ │
▼ ▼
End Retry
Un único diseño puede integrar la orquestación de supervisor, la distribución paralela, el razonamiento ReAct, la evaluación por parte de un crítico y las reintentos, implementados con LangGraph, Strands, Bedrock, AgentCore, Step Functions o código personalizado.
Elegir patrones bajo restricciones
Los presupuestos para la latencia, los tokens y la complejidad de las intervenciones de emergencia deben determinar la topología. Un pipeline secuencial es más fácil de auditar cuando a los reguladores les importa el orden. La distribución en ramas resulta útil cuando los análisis independientes ocupan la mayor parte del tiempo. Los supervisores son necesarios cuando la política de enrutamiento debe mantenerse centralizada. Los gráficos son útiles cuando se requieren puntos de control y revisión humana. Las estructuras basadas en enjambres y las transferencias libres exigen la mayor inversión en capacidad de observabilidad. Elija el plano de control más sencillo que aún permita identificar claramente los modos de fallo.
19. ¿Qué arquitectura debe utilizar?
No existe un ganador universal. Ajuste el flujo de control al problema específico. La pregunta relevante no es “¿cuál framework es el mejor?”, sino “¿qué patrón de flujo de control requiere este flujo de trabajo?”
20. La arquitectura de producción emergente
Los sistemas de producción rodean a los agentes con identidad, permisos, herramientas, estado, memoria, restricciones, mecanismos de evaluación, capacidad de observabilidad, posibilidades de reintentar, controles de costos y aprobación humana. La industria está pasando de “un agente” a “un sistema de agentes”.
21. Conclusión final
El trabajo con múltiples agentes consiste en descomponer la inteligencia y controlar la colaboración, no en crear agentes por sí mismos. ReAct razona y actúa; los supervisores delegan tareas; los grafos controlan las transiciones; las colonias descentralizan el funcionamiento; los planificadores descomponen las tareas; los críticos verifican los resultados; los humanos dan su aprobación. LangGraph y Strands (entre otros) ofrecen primitivas para su implementación. Las preguntas técnicas giran en torno a qué agentes existen, cómo colaboran, qué pueden hacer, cómo se verifican las decisiones y qué ocurre en caso de fallo.
El modelo mental a recordar
LLM
↓
Agent
↓
Multi-Agent
↓
Orchestration
↓
Tools + Memory + State
↓
Verification
↓
Observability
↓
Production Agent System
Los equipos que omiten esta vista de sistemas suelen escalar el tamaño del modelo mientras dejan la orquestación, los permisos y la evaluación como cuestiones secundarias. Esas deficiencias se manifiestan en respuestas incorrectas silenciosas, bucles infinitos en las herramientas o agentes que no pueden revertirse de forma segura. Invertir en flujos de control, verificación y controles humanos suele ser más rentable que cambiar otro modelo.
El futuro no se trata solo de modelos más inteligentes, sino también de sistemas mejores construidos en torno a ellos.