Orquestación multiagente: flujos como grafo, reintentos y topes de gasto

El problemaTus agentes funcionan por separado, pero cuando trabajan juntos se bloquean, se repiten o gastan sin control.

Son las 9:40 de un martes y Laura, directora de operaciones de una distribuidora, abre el reporte semanal de clientes. Debería estar listo desde las 8:00. No lo está. El agente que consolida ventas esperó al agente de inventario, que a su vez se quedó atorado reintentando una consulta al ERP durante 90 minutos. Nadie se enteró. Y la factura del proveedor del modelo de IA de ese día se disparó muy por encima de la de un día normal. El problema no fueron los agentes: fue la falta de orquestación multiagente.

Cuando una empresa pasa de un agente a varios, aparece un trabajo nuevo que casi nadie planea: coordinarlos. Quién va primero, quién puede trabajar al mismo tiempo, qué pasa si uno falla y cuánto se permite gastar. Este artículo explica, sin jerga, cómo se resuelve eso en un sistema que va a producción.

Por qué los agentes se estorban cuando trabajan juntos

La mayoría de los pilotos se construyen como una cadena: el agente A termina, le pasa todo al agente B, que le pasa todo al C. Funciona en la demo. En producción aparecen tres problemas.

• Todo es secuencial aunque no tenga que serlo. Si el reporte necesita datos de ventas, de inventario y de cobranza, no hay razón para que esperen uno detrás del otro.
• Un fallo detiene todo sin avisar. Si un paso se cuelga, la cadena entera se queda quieta y nadie sabe dónde.
• Nadie pone límites. Un agente que reintenta sin parar o que entra en un ciclo sigue consumiendo llamadas al modelo, y cada llamada cuesta.

La causa real no es "falta de IA". Es que el proceso no está descrito de forma que una máquina pueda coordinarlo. Esa descripción es parte del harness: la estructura que rodea al modelo y lo hace confiable (si quieres el panorama completo, revisa la anatomía de un harness empresarial).

Orquestación multiagente: el flujo como un grafo

La idea central es simple: en lugar de una cadena, el flujo se describe como un grafo, es decir, un mapa de pasos conectados por flechas. Cada paso declara de qué otros pasos depende. Con eso, el sistema puede deducir solo qué se puede hacer en paralelo y qué tiene que esperar.

Piensa en una cocina de restaurante. El chef no espera a que esté lista la salsa para empezar a picar verduras. Sabe que el emplatado depende de ambas, pero que entre sí son independientes. Un grafo le da a tus agentes esa misma lógica.

En la práctica, cada paso del grafo tiene cinco atributos:

1. Qué hace: por ejemplo, "consolidar ventas de la semana".
2. De qué depende: "necesita el cierre de facturación".
3. Cuándo se ejecuta: siempre, o solo si se cumple una condición ("solo si hay clientes con saldo vencido").
4. Qué hacer si falla: cuántos reintentos tiene y con cuánta espera entre ellos.
5. Cuánto tiempo tiene: un límite por paso; si lo excede, se marca como fallido en lugar de quedarse colgado.

Pasos condicionales

No todos los pasos deben correr siempre. Si el agente de cobranza no encuentra saldos vencidos, no tiene sentido ejecutar el paso que redacta recordatorios. Un paso condicional ahorra tiempo y dinero, y además hace el flujo más fácil de entender: lo que no aplica, no se ejecuta.

Reintentos con límite de tiempo

Los modelos y los sistemas externos fallan de vez en cuando. El reporte State of AI Engineering 2026 de Datadog encontró que 5% de las llamadas a modelos en producción devolvieron error, y que límites de capacidad, rate limits y timeouts explicaban 60% de esos errores. Es decir, la mayoría son fallos temporales que un reintento bien configurado resuelve. La clave es que el reintento tenga techo: dos o tres intentos y un tiempo máximo por paso. Sin techo, un reintento se convierte en el problema de Laura.

El orquestador y los subagentes

En un sistema multiagente bien diseñado hay un rol especial: el orquestador. No hace el trabajo de fondo; reparte tareas, recibe resultados y decide el siguiente movimiento. Los subagentes son especialistas: uno sabe de inventario, otro de cobranza, otro redacta.

Lo importante es que cada subagente trabaja con contexto aislado. Eso significa que solo recibe la información que necesita para su tarea, no todo el historial del proceso. El agente que redacta el correo al cliente no necesita ver el detalle de 4.000 movimientos de inventario; necesita el resumen y el tono de la marca. Darle solo eso tiene tres ventajas:

• Comete menos errores, porque no se distrae con información irrelevante.
• Cuesta menos, porque procesa menos texto en cada llamada.
• Es más seguro, porque un subagente no puede filtrar datos que nunca vio.

Este principio tiene nombre propio y lo desarrollamos en context engineering para empresas.

El tope de gasto por ejecución

Este es el control que más tranquilidad da a un director financiero. Cada ejecución del flujo tiene un presupuesto máximo en dólares. El sistema suma lo que cuesta cada llamada al modelo mientras el flujo avanza. Si la suma llega al tope, la ejecución se detiene, guarda lo que lleva hecho y avisa a la persona responsable.

No es un reporte que lees a fin de mes. Es un freno automático que actúa en el momento. Un agente que entra en un ciclo deja de ser una sorpresa en la factura y se convierte en una alerta con nombre, hora y paso exacto.

Un marco práctico para diseñar tu primer flujo orquestado

Si puedes llenar esta tabla en una hoja, ya tienes la mayor parte del diseño. El resto es construcción.

Ejemplo ilustrativo: el reporte semanal, antes y después

Ejemplo ilustrativo. Antes, el reporte de Laura era una cadena de cuatro agentes. Tardaba alrededor de dos horas en un buen día y nadie sabía cuánto costaba cada corrida. Cuando el ERP respondía lento, el reporte simplemente no llegaba.

Después de rediseñarlo como grafo:

• Ventas, inventario y cobranza corren en paralelo, así que el tiempo total depende del paso más lento, no de la suma.
• Si el ERP no responde, el paso de inventario reintenta tres veces y, si sigue fallando, el reporte sale con una nota clara: "inventario no disponible, datos del cierre anterior".
• El paso de recordatorios solo corre cuando hay saldos vencidos.
• Cada corrida tiene un tope de gasto. Si se alcanza, Laura recibe un aviso con el paso que lo provocó.
• Antes de enviarse a clientes, los recordatorios pasan por la aprobación humana por rol del gerente de cobranza.

El cambio importante no es la velocidad. Es que el proceso ahora es predecible: sabes qué va a pasar cuando algo sale mal.

Errores comunes al orquestar agentes

• Un solo agente gigante que hace todo. Parece más simple, pero es imposible de depurar y caro de operar.
• Reintentos infinitos. Un reintento sin límite no es resiliencia, es una fuga de dinero.
• Compartir todo el contexto con todos. Aumenta errores, costo y riesgo de filtración.
• No definir qué pasa cuando falla un paso. "Que se detenga todo" rara vez es la mejor respuesta; a veces conviene continuar con una advertencia.
• Poner el tope de gasto solo mensual. Un tope mensual te avisa cuando el daño ya está hecho; uno por ejecución lo evita.

Qué hacer el lunes

Elige un proceso que hoy involucre tres o más pasos y dibújalo en una pizarra. Marca qué depende de qué, qué podría correr al mismo tiempo y qué pasaría si cada paso fallara. Pon un número: cuánto estarías dispuesto a pagar, como máximo, por cada ejecución. Ese dibujo es el inicio de un flujo orquestado.

En Addabra construimos estos flujos sobre nuestro propio harness, con grafos de dependencias, reintentos con límite, tiempos por paso, topes de gasto por ejecución y aprobaciones humanas donde importan. Si quieres ver cómo quedaría tu proceso, empezamos por un diagnóstico.

orquestaciónagentes de IAcontrol de costos