Hay una escena que se repite en casi todos los equipos que empiezan con agentes de IA: el demo funciona de maravilla. Tres agentes conversan, delegan tareas, se pasan contexto y resuelven un problema complejo frente a tus ojos. Una semana después, en producción, el sistema se traba, gasta tokens de más, se responde a sí mismo en un loop infinito y nadie sabe qué agente hizo qué.

¿Qué pasó? El modelo era el mismo. El problema nunca fue el modelo: fue la arquitectura.

“Un sistema multi-agente no es un prompt con varios roles: es un sistema distribuido con todas sus complejidades.”

Fundamentos: qué es realmente un sistema multi-agente

Un sistema multi-agente es una arquitectura donde varios agentes autónomos colaboran para resolver una tarea que ninguno podría resolver solo de forma confiable. Cada agente tiene un rol, un contexto limitado y un conjunto de herramientas.

La tentación inicial es pensar que “más agentes = más inteligencia”. Es la forma más rápida de quemar presupuesto. La realidad es más simple: los agentes no multiplican capacidad cognitiva, dividen responsabilidad. Un agente no se vuelve más listo porque le agregues colegas; se vuelve más enfocado.

Los tres fundamentos que debes tener claros antes de diseñar:

  1. Estado explícito. En un sistema multi-agente, el estado compartido no puede vivir “en la cabeza” de cada agente. Necesitas un lugar canónico: una base de datos, un store de memoria, un archivo de contexto. Si el estado vive solo en el historial de conversación de cada agente, los agentes van a contradecirse.
  2. Contrato entre agentes. Cada agente debe exponer una interfaz clara: qué recibe, qué devuelve, qué errores puede lanzar. Trátalo como una API interna. Si los agentes se comunican con prosa libre, la depuración se convierte en una pesadilla.
  3. Límite de autonomía. Define qué puede decidir cada agente solo y qué requiere aprobación humana. Sin este límite, un agente con acceso a herramientas puede encadenar acciones irreversibles sin que nadie lo supervise.

Patrones que funcionan en producción

No necesitas inventar nada: la comunidad ya consolidó varios patrones. Estos son los que ves en sistemas que sobreviven al contacto con usuarios reales.

1. Supervisor (orquestador central)

Un agente supervisor recibe la tarea, la descompone, delega subtareas a agentes especializados y consolida los resultados. Es el patrón más usado porque es el más fácil de razonar y depurar.

Usuario → Supervisor → [Agente investigador, Agente redactor, Agente validador]
                        ↓ resultados parciales
              Supervisor consolida → Respuesta final

Cuándo usarlo: tareas que se pueden descomponer en pasos claros y donde la calidad del resultado depende de revisar el trabajo de cada paso.

2. Pipeline (cadena de especialistas)

Cada agente procesa el output del anterior. Es el patrón natural para flujos de transformación: extraer datos → limpiarlos → estructurarlos → resumirlos.

Cuándo usarlo: procesos con etapas bien definidas y dependencia lineal. Es el más barato en tokens y el más fácil de testear: puedes validar la salida de cada etapa.

3. Equipo con herramientas compartidas

Varios agentes acceden a un mismo conjunto de herramientas (búsqueda, base de datos, APIs) y compiten o cooperan por resolver la tarea. Aquí aparece el problema clásico: quién tiene el turno de hablar. Sin un mecanismo de control, dos agentes pueden escribir al mismo repositorio o esperarse indefinidamente.

Cuándo usarlo: tareas donde la exploración paralela acelera el resultado (investigación, generación de variantes) y donde el estado se puede aislar por agente.

Orquestación: el arte de coordinar sin que se desmadre

La orquestación es donde mueren la mayoría de los sistemas multi-agente. Tres decisiones marcan la diferencia:

1. Síncrono vs. asíncrono. Para tareas cortas y dependientes, la llamada síncrona es suficiente. Para flujos largos (procesar un lote de documentos, generar contenido a escala), necesitas una cola de trabajo: los agentes encolan tareas, un worker las procesa y un estado persistente guarda el progreso. Así, si un agente falla, la tarea no se pierde: se reintenta.

2. Control de flujo explícito. No dejes que los agentes decidan solos cuándo terminar. Un generador de artículos que “decide” que ya terminó puede quedarse en un loop de automejora infinito. Define condiciones de salida: máximo de iteraciones, criterio de validación, timeout global.

3. Observabilidad por agente. Cada agente debe emitir logs estructurados: qué entrada recibió, qué herramientas llamó, cuántos tokens usó, qué decidió. Cuando algo sale mal (y va a salir mal), tu primera pregunta va a ser “¿qué hizo el agente de redacción con este dato?”. Si no tienes esa respuesta, estás depurando a ciegas.

# Ejemplo mínimo de supervisor con límite de iteraciones
def run_supervisor(task, agents, max_iterations=5):
    context = {"task": task, "history": []}
    for i in range(max_iterations):
        plan = agents["planner"].run(context)
        if plan["done"]:
            return plan["result"]
        for step in plan["steps"]:
            result = agents[step["agent"]].run(step, context)
            context["history"].append(result)
    raise TimeoutError("Supervisor excedió el máximo de iteraciones")

Errores comunes (y cómo evitarlos)

Estos son los cinco errores que veo repetirse en equipos de LATAM que están arrancando con agentes:

  1. Agentes que se pasan contexto gigante. Cada agente recibe el historial completo del sistema y los costos de tokens se disparan. Solución: contexto acotado por rol. El agente de datos no necesita leer la conversación completa; necesita el esquema y el dato puntual.
  2. Sin validación de salida. Confiar en que el agente “siempre va a devolver JSON válido” es una receta para el desastre. Valida con schemas (Pydantic, Zod) y reintenta con el error como feedback.
  3. Mezclar roles y herramientas. Si un agente tiene demasiadas herramientas, gasta tiempo decidiendo cuál usar y comete más errores. Menos herramientas por agente, más predictibilidad.
  4. Ignorar los costos. Un loop de agentes que se automejoran puede consumir el presupuesto del mes en una tarde. Pon topes duros de tokens e iteraciones desde el día uno.
  5. Diseñar para la demo, no para el fallo. En la demo todo sale bien. En producción, las APIs fallan, los modelos devuelven basura y los usuarios hacen lo inesperado. Diseña el sistema asumiendo que cada paso puede fallar: reintentos, fallbacks y degradación elegante.

El camino práctico

Si estás empezando, no construyas un sistema de cinco agentes en tu primer proyecto. Empieza con un solo agente con herramientas, domina el flujo de errores y validación, y recién entonces agrega un segundo agente para una tarea que realmente lo justifique.

La regla de oro: cada agente que agregas multiplica la superficie de fallo. Un sistema de dos agentes bien orquestados supera a uno de ocho que nadie entiende. La arquitectura no es un lujo: es lo que separa un experimento interesante de un sistema que tu equipo puede operar a las 3 de la mañana cuando algo falla.

“Cada agente que agregas multiplica la superficie de fallo: la buena arquitectura es la que puedes operar cuando algo sale mal.”

Sigue explorando estos temas en el blog de DojoFullStack, donde profundizamos en agentes de código, automatización y las arquitecturas que separan a los equipos que avanzan de los que se quedan. Y si quieres llevar esto al siguiente nivel, en DojoFullStack formamos desarrolladores que no solo escriben código, sino que diseñan sistemas de IA que trabajan solos, de forma confiable y a escala.