Sistemas multi-agente: cuándo usarlos y cómo diseñarlos

La mayoría de los problemas no necesitan múltiples agentes. Pero los que sí los necesitan, los necesitan de verdad.

Un sistema multi-agente bien diseñado puede hacer cosas que un único agente no puede: ejecutar tareas en paralelo, especializar el conocimiento, superar el límite de la context window, y añadir capas de verificación.

Cuándo tiene sentido un sistema multi-agente

Un solo agente es suficiente si la tarea:

• Cabe en una sola context window
• Tiene pasos secuenciales sin paralelismo útil
• No requiere conocimiento altamente especializado en dominios diferentes

Necesitas múltiples agentes cuando:

La tarea es demasiado larga para una sola ventana — Analizar 50 documentos, procesar un repositorio de código entero, investigar un tema desde múltiples fuentes.

Partes de la tarea se pueden hacer en paralelo — Mientras un agente busca en base de datos, otro consulta una API externa, otro genera el borrador.

Requiere conocimiento especializado diferente — Un agente experto en código, otro en redacción, otro en verificación de datos.

Quieres verificación independiente — Un agente genera, otro crítica. El resultado es mejor que si el mismo agente hace las dos cosas.

Los 4 patrones principales

1. Orquestador + Subagentes

Un agente central recibe la tarea, la divide, delega a subagentes especializados y consolida resultados.

Usuario → Orquestador → [Agente investigación]
                      → [Agente redacción]
                      → [Agente verificación]
                      ↓
               Respuesta consolidada

Es el patrón más común. El orquestador no necesita saber hacer las tareas; solo necesita saber a quién delegarlas.

2. Pipeline secuencial

Los agentes se encadenan: la salida de uno es la entrada del siguiente.

[Extracción] → [Análisis] → [Síntesis] → [Formato] → Resultado

Útil cuando hay etapas claras con transformaciones sucesivas. Fácil de debuggear porque puedes inspeccionar el estado entre cada agente.

3. Paralelo + Agregador

Varios agentes trabajan simultáneamente sobre el mismo problema o partes diferentes, y un agente agrega los resultados.

Input → [Agente 1] ↘
       → [Agente 2] → Agregador → Output
       → [Agente 3] ↗

Útil para: análisis de múltiples documentos, consultas a múltiples fuentes, generación de múltiples propuestas para elegir la mejor.

4. Debate / Crítica

Un agente genera, otro critica, el primero refina. Puede haber varias rondas.

[Generador] → borrador → [Crítico] → feedback → [Generador] → versión final

Produce resultados de mayor calidad a cambio de más latencia y costo. Vale la pena para tareas donde la calidad importa más que la velocidad.

Coordinación: cómo los agentes se comunican

Por mensajes (message passing)

Los agentes se comunican enviando mensajes estructurados. Cada agente tiene una cola de entrada y salida.

Por estado compartido

Los agentes leen y escriben en un estado compartido (un objeto, una base de datos):

estado = {
    "tarea_original": "...",
    "subtareas": [...],
    "resultados": {},
    "estado_actual": "investigando"
}

Cada agente actualiza su parte del estado. El orquestador lee el estado para decidir qué sigue.

Por herramientas

Un agente "llama" a otro como si fuera una herramienta:

tools = [
    {
        "name": "agente_investigacion",
        "description": "Busca información sobre un tema",
        "parameters": {"query": "string"}
    }
]

Esta abstracción es limpia: desde el punto de vista del agente orquestador, no importa si es una función, una API o otro LLM.

Gestión del contexto en sistemas multi-agente

El problema central: ¿qué sabe cada agente?

Contexto mínimo: Cada agente recibe solo lo necesario para su subtarea. Más eficiente, menos riesgo de confusión.

Contexto completo: Todos los agentes ven todo. Más coherencia, más tokens, más caro.

Contexto jerárquico: El orquestador tiene el contexto completo. Los subagentes solo reciben lo relevante para ellos.

La regla práctica: dale a cada agente el contexto mínimo necesario para hacer bien su trabajo.

Fallos comunes

El orquestador sobrecomplex — Si el agente orquestador tiene que tomar demasiadas decisiones complejas, simplifica la arquitectura o añade un subagente para la lógica de decisión.

Loops infinitos — Sin límites de iteraciones, los agentes pueden seguir pasándose la tarea. Siempre pon un máximo de rondas.

Estado inconsistente — Si varios agentes modifican el mismo estado sin coordinación, pierdes coherencia. Usa escrituras atómicas o un agente coordinador de estado.

Sin mecanismo de fallo — Define qué pasa cuando un subagente falla. ¿Reintenta? ¿El orquestador maneja el error? ¿Se para todo?

Costo descontrolado — Los sistemas multi-agente multiplican el costo por número de agentes y rondas. Mide antes de poner en producción.

Herramientas

• LangGraph — framework de grafos para agentes, bueno para flujos con estado
• CrewAI — abstracción de alto nivel para equipos de agentes
• AutoGen (Microsoft) — sistema de conversaciones entre agentes
• Claude con tool use — puedes implementar multi-agente directamente con la API de Anthropic usando herramientas

¿Empezar con multi-agente o con un solo agente?

Siempre empieza con el sistema más simple posible.

Un solo agente bien construido supera a un sistema multi-agente mal diseñado. La complejidad de coordinar agentes introduce puntos de fallo, latencia y costo.

Añade agentes cuando tengas evidencia de que el sistema simple no puede hacer el trabajo, no como arquitectura de partida.

---

Recursos relacionados:

• Canvas de diseño de agente — diseña tu arquitectura multi-agente
• Checklist de Agente de IA — 35 puntos antes de ir a producción
• Qué es un agente de IA — los fundamentos
• Qué es tool calling — cómo los agentes usan herramientas