Comparación de cuatro patrones de sistemas multiagente: subagentes, habilidades, transferencias y enrutadores.

Una historia familiar: un equipo construye un sistema de agentes complejo con varios modelos, rutas entrelazadas y agentes que generan otros agentes, para luego descubrir que una versión con un solo agente, creada apresuradamente en un fin de semana, supera al sistema original en términos de latencia, facilidad de depuración y todas las demás métricas importantes. Salir de esa trampa comienza al darse cuenta de que casi todos los sistemas multiagente serios se basan en cuatro patrones, y al saber qué cuesta cada uno y qué aporta.

¿Es realmente necesario utilizar múltiples agentes?

Por lo general, no. Es común recurrir a un marco de trabajo multiagente desde la primera semana, impulsado por el entusiasmo y el atractivo de un diagrama lleno de flechas; sin embargo, el resultado suele ser frágil y costoso, cuando en realidad un solo agente con instrucciones adecuadas habría funcionado mejor.

Dos situaciones justifican el uso de herramientas adicionales. Una es el límite de la ventana de contexto: no se puede incluir análisis legal, codificación médica, modelado financiero y manejo de sentimientos en una sola solicitud esperando un resultado coherente, ya que un contexto sobrecargado reduce la calidad y ralentiza las respuestas. La otra es la distribución de responsabilidades entre equipos: cuando un equipo se encarga del inventario y otro de la ejecución de pedidos, hacer que compartan una sola solicitud monolítica genera conflictos, implementaciones defectuosas y confusión sobre quién es responsable de qué. Ante cualquiera de estos problemas, los patrones que se describen a continuación se convierten en una solución práctica en lugar de una arquitectura por sí misma.

Subagentes: el jefe de gabinete

Imagínese a un jefe de personal que nunca realiza el trabajo personalmente, pero sabe exactamente a quién recurrir. Un agente supervisor principal tiene una visión general de todo. Cuando es necesario obtener datos de CRM, redactar un correo electrónico o realizar un cálculo, se invoca a un subagente especializado como si fuera una herramienta, se recibe el resultado y luego se reúne todo en conjunto.

Lo importante es la limpieza. Cada subagente trabaja de forma aislada en su propio contexto restringido, por lo que nada se mezcla entre los dominios: el subagente legal no sabe nada sobre el inventario. Ese aislamiento resulta beneficioso cuando los dominios son grandes y distintos, ya que cada especialista puede seguir instrucciones detalladas sin competir por espacio con material no relacionado. También facilita las pruebas, ya que se puede evaluar a un subagente por separado. El costo es una llamada adicional al modelo por solicitud, ya que los resultados deben remontarse a través del supervisor; por lo tanto, tres subagentes significan tres viajes adicionales. Las aplicaciones sensibles a la latencia lo perciben rápidamente.

Es adecuado para plataformas de investigación que asignan tareas a especialistas en cada área, asistentes personales que coordinan calendarios, correos electrónicos y tareas al mismo tiempo, y sistemas de triaje en salud donde un agente principal envía instrucciones a subagentes clínicos de forma paralela. Un estudio publicado muestra que un conjunto de modelos, con un modelo grande como líder y modelos más pequeños como subagentes, superó a un modelo grande independiente en más del 90% en pruebas internas. El razonamiento paralelo en ventanas de contexto separadas resulta muy útil cuando la tarea lo requiere.

Habilidades: un agente, múltiples funciones

Técnicamente sigue siendo un único agente, aunque no actúa como tal. Comienza cada conversación sabiendo solo los nombres y las breves descripciones de las habilidades disponibles, y carga el contexto completo de una habilidad cuando surge algo relevante. Un médico generalista funciona de la misma manera: consulta el protocolo especializado cuando aparece una condición específica en lugar de memorizarlos todos para cada consulta.

La ventaja práctica es la independencia. Un equipo de Python se encarga de mantener la habilidad en Python y un equipo de bases de datos se ocupa de las habilidades en SQL, cada uno como su propio paquete, sin que nadie coordine mediante un prompt compartido. Para las organizaciones de ingeniería distribuida, eso representa un gran alivio. El inconveniente es la acumulación de tokens: cuanto más tiempo dura la conversación y más habilidades se cargan, más pesado se vuelve el contexto, lo que eventualmente afecta negativamente tanto los costos como la calidad hacia el final de la sesión. Es manejable, pero es un problema real.

Las habilidades adecuadas incluyen a los asistentes de programación que alternan entre modos frontend, backend e infraestructura, las herramientas creativas que cambian de estilo de escritura, y a los agentes de soporte que aplican conocimientos especializados según el problema real del cliente.

Traspasos de responsabilidad: la carrera de relevos

Si las subagencias representan la delegación paralela y las habilidades la especialización dinámica, los traspasos de responsabilidad son una progresión secuencial, similar a cómo las personas avanzan a través de un proceso complicado. Un usuario comienza con el Agente A. Una vez que se dice algo o se cumple una condición, el control pasa al Agente B, que cuenta con su propio prompt del sistema, herramientas y quizás personalidad, y posteriormente al Agente C. Durante todo este proceso, el estado, es decir, todo lo que se ha discutido y decidido, se transmite con cada transferencia.

Las transiciones están determinadas por el estado. Los agentes no se comunican simplemente entre sí; actualizan el estado compartido, y ese estado decide quién será el siguiente en estar activo. En efecto, se trata de una máquina de estados en la que los agentes son los estados mismos.

Esa es una estructura natural para flujos de soporte en múltiples etapas (triage, luego diagnóstico, luego resolución), procesos legales donde las verificaciones de conflictos deben realizarse antes de aceptar el caso, y flujos de pago donde no se puede comenzar a procesar el pago hasta que el carrito esté confirmado. El equilibrio que la gente olvida es que la secuencialidad implica la ausencia de paralelismo: si es necesario consultar tres bases de conocimiento al mismo tiempo, hay que buscar otra solución. Es adecuado para flujos de trabajo en los que el Paso B realmente no puede comenzar hasta que termine el Paso A. La gestión de estados también es compleja, y cuando se rompe una cadena de transferencias, depurar no es sencillo; por lo tanto, destine tiempo adicional a herramientas de rastreo y observabilidad antes de optar por este enfoque.

Router: el controlador de tráfico aéreo

Conceptualmente es simple. Algo en la capa frontal clasifica cada consulta entrante y la envía al especialista o especialistas adecuados. Ellos trabajan en paralelo y sus resultados se combinan en una sola respuesta. El enrutador no mantiene estado, por lo que cada solicitud se procesa de forma independiente.

Su ventaja radica en el rendimiento. Una pregunta que abarca tres dominios de conocimiento llega a los tres agentes al mismo tiempo, y el tiempo total es aproximadamente el del llamado más lento, no la suma de los tiempos. En una base de conocimiento empresarial, la pregunta de un empleado podría relacionarse con políticas de recursos humanos, pautas de seguridad informática y cumplimiento financiero; el enrutador activa a los tres agentes al mismo tiempo y sintetiza una sola respuesta, algo que de otra forma requeriría tres consultas o un agente sobrecargado que gestionara los tres dominios.

El límite real es que ser sin estado implica no tener memoria. Una pregunta posterior llega sin rastro de lo anterior, lo cual representa un problema real para los productos de conversación. La solución habitual consiste en envolver al router en un agente externo con estado que guarda el historial, aunque eso combina patrones y añade complejidad. Los routers son adecuados para sistemas de alto volumen con áreas bien separadas, para cualquier cosa que necesite varias fuentes de conocimiento simultáneamente, y en casos donde la consistencia por solicitud es más importante que la continuidad de la conversación.

Elegir

No tiene por qué ser angustiante.

• Varios dominios distintos, ejecución paralela limpia y punto de control centralizado hacia subagentes.
• Un agente con muchas especializaciones, gestionado por equipos diferentes, que apunta a las habilidades disponibles.
• Un flujo de trabajo inherentemente secuencial, con condiciones previas y estado transferido, que indica los puntos de transferencia.

Grandes volúmenes de consultas en diferentes áreas que requieren trabajo en paralelo sin historial de conversación indican la necesidad de un enrutador.

Otra consideración es el rendimiento. Los patrones, habilidades y transferencias de estado permiten ahorrar aproximadamente del 40 al 50 por ciento en las llamadas al modelo en solicitudes repetidas, ya que recuerdan el contexto anterior. Los subagentes y los enrutadores no tienen estado y generan el mismo costo cada vez, pero a cambio obtienen una fuerte isolación de contexto, lo cual es importante para cargas de trabajo en paralelo en dominios extensos.

La moderación es lo primero

No construyas sistemas multiagente solo para parecer sofisticado; créalos para resolver un problema con el que realmente te hayas encontrado. Una progresión sensata consiste en comenzar con un agente que reciba instrucciones realmente buenas, luego añadir herramientas, y solo después adoptar patrones multiagente, una vez que te enfrentes a obstáculos concretos como el desbordamiento de contexto, las dificultades en la responsabilidad dentro del equipo o la necesidad de paralelismo que un solo agente no puede satisfacer. Los equipos que cuentan con los mejores sistemas suelen ser aquellos que resistieron la complejidad durante más tiempo y pudieron explicar por qué cada componente existía.

Qué viene a continuación

Considere estos cuatro patrones como la gramática básica del diseño multiagente en la actualidad, con un nuevo vocabulario que aparece rápidamente. Los agentes locales persistentes que conservan la memoria entre sesiones y se conectan a archivos y aplicaciones personales están pasando de la investigación a los productos reales. El Protocolo de Contexto de Modelo, del que se informó que tenía 97 millones de instalaciones a principios de 2026, se está convirtiendo en la infraestructura que permite a los agentes de diferentes proveedores comunicarse sin necesidad de integraciones personalizadas. Están comenzando a aparecer redes de agentes que generan nuevos agentes de forma dinámica, escalando su propio equipo según la complejidad de la tarea. Los subagentes, las habilidades, las transferencias de responsabilidades y los enrutadores son la base de todo esto, por lo que dominarlos ahora brinda una ventaja. Una regla práctica para decidir: primero escriba el problema concreto, nombre el patrón que lo resuelve y solo luego dibuje el diagrama. Comience de forma sencilla, sea honesto sobre lo que necesita, y cuando pase a utilizar múltiples agentes sabrá qué opción elegir.

Leer más

• RAG-Anything en 65 libros sobre vino: dónde triunfa y falla la recuperación de grafos: Una prueba práctica del grafo de conocimientos de RAG-Anything en 65 PDFs sobre vino: elección del analizador, costos, respuestas basadas en grafos frente a vectores, y el punto ciego con los vinos espumosos.
• Comparación de 16 arquitecturas RAG: qué patrón se adapta a qué problema: Un recorrido por dieciséis patrones RAG en cuatro niveles, desde recuperación estándar e híbrida hasta diseños basados en agentes, grafos y federados, con un orden de construcción mes a mes.
• Ingeniería de contexto para sistemas multiagente: por qué fallan las transferencias entre pasos: Los agentes rara vez fallan dentro de un único paso. Fallan entre pasos, cuando llega el contexto incorrecto. Cómo diseñar el estado, el enrutamiento y la calidad del contexto en LangGraph.
• Agentes de IA contra backends tradicionales: flujo de control, costos y modos de fallo: Compare un backend determinista con un bucle de agentes LLM utilizando un ejemplo de reembolso: latencia, costos de tokens, crecimiento del contexto, modos de fallo y dónde encaja mejor un diseño híbrido.
• Por qué la orquestación supera al número de agentes en un panel de entrevistas multiagente: Construir un panel de entrevistas local con Ollama y Qwen3 muestra por qué el enrutamiento, el estado estructurado y las restricciones son más importantes que añadir más agentes de LLM.
• Cuatro estrategias de memoria para agentes de AI: ventanas deslizantes, FAISS y GraphRAG: Compare formas de proporcionar memoria a un agente de LLM, desde historial completo y ventanas deslizantes hasta índices invertidos, búsqueda semántica FAISS y un grafo de conocimiento GraphRAG.
• Informes de la comunidad GraphRAG: Convierte un grafo de conocimiento en respuestas: Cómo GraphRAG construye un grafo a partir de texto, identifica comunidades mediante el método jerárquico de Leiden, genera informes de las comunidades y los utiliza para búsquedas globales y locales.