Agent Orchestration in 2026: What Works

La brecha

Construir un agente de IA es un proyecto de fin de semana. Eliges un modelo, defines algunas herramientas, escribes un system prompt, lo despliegas. Los tutoriales están por todas partes. Los frameworks abundan. Las demos son impresionantes. Y entonces alguien te pide construir un sistema donde cinco agentes colaboran en un informe de investigación, tres de ellos ejecutando código en paralelo, todos compartiendo contexto de forma eficiente, y convergiendo en una salida coherente — y te das cuenta de que el proyecto de fin de semana era la parte fácil.

La brecha entre "construí un agente" y "construí un sistema de agentes" es la misma brecha que separó el scripting de los sistemas distribuidos hace dos décadas. Un script Python de un solo hilo es conceptualmente simple. Un sistema distribuido con colas de mensajes, protocolos de consenso, recuperación ante fallos y observabilidad es un desafío de ingeniería fundamentalmente diferente. Los sistemas multi-agente de IA están pasando por la misma transición ahora mismo, y la mayor parte de la industria no se ha puesto al día.

Los problemas son inquietantemente familiares. ¿Cómo descompones una tarea compleja en subtareas que se puedan paralelizar? ¿Cómo gestionas el estado compartido sin corrupción? ¿Cómo manejas fallos parciales con elegancia? ¿Cómo depuras un sistema donde el comportamiento es emergente en lugar de prescrito? Estas son las mismas preguntas que los ingenieros de sistemas distribuidos llevan décadas respondiendo — pero las respuestas específicas para agentes de IA aún se están escribiendo.

Durante el último año en Midas Labs, hemos construido, roto y reconstruido sistemas multi-agente para cargas de trabajo en producción. Hemos probado los principales frameworks, creado nuestras propias capas de orquestación y evaluado herramientas open source como DeerFlow que toman enfoques diferentes al problema. Lo que sigue es una inmersión técnica en lo que hemos aprendido: los problemas centrales, los patrones que funcionan, los que no, y una evaluación honesta de lo que sigue roto.

Descomposición de tareas

El primer problema en cualquier sistema multi-agente es el mismo primer problema en cualquier sistema paralelo: ¿cómo divides una tarea compleja en subtareas que se puedan ejecutar concurrentemente? En el mundo de los agentes, hay tres enfoques dominantes, cada uno con compensaciones reales.

Los DAGs estáticos definen el grafo de tareas por adelantado. Sabes de antemano que el Paso A alimenta al Paso B, que alimenta al Paso C. El grafo es fijo antes de que comience la ejecución. Así es como funcionan la mayoría de los motores de flujo de trabajo tradicionales, y es como muchos frameworks de agentes implementan tareas de múltiples pasos.

Los DAGs estáticos son predecibles, testeables y fáciles de razonar. Puedes visualizar el grafo de ejecución, estimar costos de tokens por adelantado y configurar monitoreo en cada nodo. La desventaja es la rigidez. Si la tarea no encaja en el grafo predefinido — si la clasificación revela que la entrada necesita un pipeline de procesamiento completamente diferente — el DAG no puede adaptarse. Terminas construyendo ramas condicionales cada vez más complejas para manejar casos extremos, y eventualmente el DAG "estático" se convierte en un lío enredado de casos especiales.

La planificación dinámica toma el enfoque opuesto. El agente observa el estado actual, decide qué hacer a continuación, ejecuta, observa de nuevo y repite. No hay grafo predefinido. El modelo es el planificador.

La planificación dinámica es máximamente flexible. El agente puede manejar cualquier entrada, pivotar cuando aparecen resultados inesperados y explorar caminos de solución que no se anticiparon en tiempo de diseño. La desventaja es la impredecibilidad. No puedes estimar cuántos pasos tomará una tarea, cuántos tokens consumirá, o si el agente se irá por un camino que desperdicia recursos sin producir resultados útiles. En producción, la impredecibilidad es un riesgo. Necesitas poder establecer presupuestos, definir SLAs y garantizar la terminación.

La descomposición jerárquica es el punto medio que hemos encontrado que funciona mejor para sistemas en producción. Un agente líder recibe la tarea compleja y la descompone en subtareas, cada una asignada a un sub-agente especializado. El agente líder planifica estáticamente, pero los sub-agentes pueden planificar dinámicamente dentro de su alcance. Es un DAG de planificadores, no un DAG de pasos.

Este enfoque te da la predecibilidad de los DAGs estáticos en el nivel superior — puedes estimar la cantidad de subtareas, establecer presupuestos por subtarea y monitorear el progreso — mientras preservas la flexibilidad de la planificación dinámica dentro de cada subtarea. El agente líder proporciona estructura; los sub-agentes proporcionan adaptabilidad. Refleja cómo funcionan los equipos humanos efectivos: un gerente de proyecto descompone el trabajo, los especialistas lo ejecutan y el gerente sintetiza los resultados.

Gestión de contexto

La ventana de contexto es la restricción fundamental de todo sistema basado en LLM. Es finita, costosa y compartida entre todo lo que el modelo necesita saber: system prompts, historial de conversación, definiciones de herramientas, resultados intermedios y la entrada real. En un sistema multi-agente, esta restricción se multiplica. Cada agente tiene su propia ventana de contexto, y el agente líder necesita mantener contexto sobre el estado de todos los sub-agentes. Sin una gestión cuidadosa, el agotamiento del contexto es el resultado por defecto.

El enfoque ingenuo es el relleno de contexto: cargar todo en la ventana de contexto y dejar que el modelo lo ordene. Esto funciona sorprendentemente bien para tareas simples con contextos cortos. Falla catastróficamente para tareas complejas. Un system prompt de 50 herramientas consume 3,000 tokens antes de que el usuario diga nada. Un historial de conversación que incluye cada resultado intermedio crece linealmente con la complejidad de la tarea. Para cuando llevas 50 interacciones, el modelo está gastando la mayor parte de su atención en contexto irrelevante del inicio de la conversación, y la calidad de su salida se degrada en consecuencia.

La ingeniería de contexto es el conjunto de técnicas que gestionan esta restricción intencionalmente. Las estrategias más efectivas que hemos encontrado son:

Carga progresiva de habilidades. No incluyas todas las herramientas en cada prompt. Mantén un registro de herramientas disponibles y carga solo las relevantes para la subtarea actual. Un agente de investigación no necesita acceso a herramientas de ejecución de código. Un agente de formato no necesita búsqueda web. Cargar herramientas bajo demanda reduce el costo base de contexto de miles de tokens a cientos.

Resumen agresivo. Cuando una subtarea se completa, reemplaza la traza de ejecución completa con un resumen de 2-3 oraciones. Los detalles se preservan en logs para depuración, pero la ventana de contexto solo lleva el resultado. Esta es la técnica de gestión de contexto más efectiva que hemos implementado — típicamente reduce el crecimiento del contexto en un 80% con pérdida de información insignificante.

Descarga al sistema de archivos. En lugar de mantener resultados intermedios en contexto, escríbelos en el sistema de archivos y referéncialos por ruta. El agente puede leerlos de vuelta cuando sea necesario, pero no consumen contexto cuando no se están usando activamente. Esto es particularmente efectivo para tareas de generación de código, donde las salidas intermedias pueden ser de miles de tokens.

Aislamiento y seguridad

Cuando los agentes ejecutan código, necesitan sandboxes. Esto no es una característica de seguridad opcional — es un requisito arquitectónico fundamental para cualquier sistema donde múltiples agentes trabajan concurrentemente. Sin aislamiento, los agentes interfieren entre sí. El Agente A instala un paquete que rompe el entorno del Agente B. El Agente C modifica un archivo que el Agente D está leyendo. Los modos de fallo son no determinísticos, difíciles de reproducir y devastadores de depurar.

Los contenedores Docker son el mecanismo de aislamiento más común, y con buena razón. Cada agente obtiene su propio sistema de archivos, su propio espacio de procesos y su propio namespace de red. El contenedor puede iniciarse en segundos, precargado con las herramientas y dependencias que el agente necesita, y destruirse cuando la tarea se completa. La limpieza es trivial: destruye el contenedor y el estado desaparece.

Pero el aislamiento va más allá de los contenedores. Un sandboxing efectivo también significa permisos delimitados — el Agente A puede leer del directorio de entrada compartido pero solo puede escribir en su propio directorio de salida. Significa límites de recursos — ningún agente puede consumir todo el CPU o memoria disponible. Y significa aislamiento de red — los agentes no pueden hacer peticiones salientes arbitrarias a menos que se permita explícitamente. El principio es defensa en profundidad: incluso si una capa falla, las otras contienen el radio de explosión.

El costo del aislamiento es el overhead. Iniciar un contenedor Docker toma tiempo. Ejecutar cinco entornos separados consume más memoria que ejecutar cinco hilos en un solo proceso. Pero para sistemas multi-agente en producción, este overhead es una característica, no un defecto. La alternativa — depurar fallos no determinísticos causados por corrupción de estado compartido entre agentes — es vastamente más costosa que los segundos extra de inicio de contenedor.

Convergencia

Los sub-agentes producen resultados. Esos resultados necesitan convertirse en una única salida coherente. Este es el problema de convergencia, y es más difícil de lo que parece. Cuando tres agentes investigan independientemente el mismo tema, producen tres perspectivas que pueden superponerse, contradecirse o complementarse. El agente líder necesita sintetizar estas perspectivas en algo que se lea como si hubiera sido escrito por un solo autor con un punto de vista coherente.

El patrón que funciona es un pipeline de múltiples etapas. Primero, una puerta de validación verifica que cada sub-agente realmente completó su tarea asignada y produjo una salida en el formato esperado. Las salidas malformadas o incompletas se marcan para reintento o revisión manual. Segundo, un paso de resolución de conflictos identifica contradicciones entre las salidas de los sub-agentes y las resuelve — ya sea seleccionando la fuente más autoritativa, sintetizando una perspectiva equilibrada, o marcando el conflicto para revisión humana. Tercero, el paso de síntesis teje las salidas validadas y desconflictuadas en un único resultado coherente.

La tentación es saltarse los pasos intermedios y simplemente volcar todas las salidas de sub-agentes en un solo prompt: "Aquí hay tres resúmenes de investigación. Combínalos en un documento." Esto funciona para casos simples pero falla cuando las apuestas son altas. Sin validación, obtienes citas alucinadas que se filtran desde un sub-agente que malinterpretó su tarea. Sin resolución de conflictos, obtienes párrafos que se contradicen entre sí. El enfoque de múltiples etapas cuesta más tokens pero produce resultados dramáticamente mejores.

Caso de estudio: DeerFlow

DeerFlow (gio-moros/deer-flow) es un framework open source de orquestación de agentes que aborda estos cuatro problemas como preocupaciones de primera clase. En lugar de agregar soporte multi-agente a un framework de agente único, DeerFlow fue construido desde cero para sistemas donde los agentes colaboran en tareas complejas. Así es como maneja cada desafío.

La descomposición de tareas en DeerFlow sigue el modelo jerárquico. El agente líder recibe la descripción completa de la tarea y la descompone en subtareas tipadas, cada una con entradas explícitas, salidas esperadas y requisitos de recursos. El tipado es importante — significa que el framework puede validar que las salidas de los sub-agentes coincidan con los esquemas esperados antes de intentar la convergencia. Una subtarea de investigación produce un resumen de investigación estructurado, no texto arbitrario.

La gestión de contexto utiliza carga progresiva de habilidades y resumen agresivo. Cada sub-agente recibe solo las herramientas relevantes para su subtarea, cargadas desde un registro de habilidades bajo demanda. Cuando un sub-agente completa, su traza de ejecución completa se resume en un objeto de resultado estructurado, y la traza se persiste en el sistema de archivos. El contexto del agente líder se mantiene liviano independientemente de cuántas subtareas se hayan completado.

El aislamiento se implementa a través de contenedores Docker con directorios de trabajo dedicados. Cada sub-agente tiene su propio sistema de archivos, su propio conjunto de variables de entorno y su propia configuración de red. El framework maneja el ciclo de vida del contenedor automáticamente: iniciar, ejecutar, recopilar resultados, destruir. La contaminación entre sesiones es imposible por construcción, no por convención.

La convergencia ocurre a través de un sistema de salida multicanal. Los resultados de los sub-agentes fluyen de vuelta al agente líder a través de un pipeline estructurado que valida salidas, resuelve conflictos y sintetiza el resultado final. La salida puede entregarse a través de múltiples canales — Telegram, Slack, interfaz web, o directamente a otro sistema de agentes vía MCP — sin cambiar la lógica de orquestación.

Lo elegante de DeerFlow es la separación de preocupaciones. El agente líder no sabe ni le importa cómo los sub-agentes ejecutan sus tareas. Los sub-agentes no saben ni les importa el contexto más amplio de la tarea. La capa de orquestación media todo, lo que significa que puedes intercambiar sub-agentes, cambiar entornos de ejecución o modificar estrategias de convergencia sin tocar el resto del sistema.

Lo pragmático son las elecciones tecnológicas. DeerFlow está construido sobre LangGraph, que proporciona una base madura para la gestión del estado de agentes. Usa Docker para aislamiento, que es bien entendido y bien equipado con herramientas. Soporta MCP para extensibilidad, que se está convirtiendo en el protocolo estándar para interoperabilidad de agentes. Ninguna de estas elecciones es novedosa — son tecnologías probadas aplicadas cuidadosamente al problema de orquestación de agentes.

Lo que sigue sin resolver es la visibilidad en el proceso de orquestación. Cuando una tarea de 5 agentes produce un resultado inesperado, es difícil determinar qué agente se equivocó, en qué punto y por qué. Las trazas de ejecución están disponibles, pero no existe un equivalente de un sistema de trazado distribuido (como Jaeger o Zipkin) construido a propósito para flujos de trabajo multi-agente. Esta es la próxima frontera para el framework.

Patrones que funcionan

Después de un año construyendo sistemas multi-agente, cuatro patrones han demostrado ser consistentemente fiables en diferentes dominios, complejidades de tareas y tamaños de equipo. Estas no son recomendaciones teóricas — son patrones que hemos validado en producción y seguimos usando diariamente.

Lo que sigue roto

La honestidad intelectual requiere reconocer lo que aún no funciona. Los sistemas multi-agente en 2026 tienen cuatro brechas importantes que ningún framework ha abordado completamente, incluyendo DeerFlow. Estas no son inconvenientes menores — son desafíos fundamentales que limitan la fiabilidad y escalabilidad de las arquitecturas multi-agente.

La depuración es brutal. Cuando un pipeline de 5 agentes produce un resultado incorrecto, determinar qué agente tomó la decisión equivocada es un proceso manual que consume mucho tiempo. Necesitas leer las trazas de ejecución de cada agente, correlacionar timestamps, identificar dónde el razonamiento se desvió, y descifrar si el problema fue en la descomposición de tareas, la ejecución o la convergencia. No hay equivalente de console.log para el razonamiento multi-agente. Herramientas de trazado distribuido como Jaeger existen para microservicios, pero nada equivalente existe para la orquestación de agentes. Alguien lo construirá, pero aún no existe.

El testing es costoso. Las pruebas unitarias para agentes son esencialmente inútiles. Puedes probar que una llamada a herramienta devuelve el formato correcto, pero no puedes probar que un agente tomará la decisión correcta en contexto — porque la decisión depende del modelo, el contexto y la redacción específica del prompt, todos los cuales varían de forma no determinística. Las pruebas de integración funcionan pero cuestan dinero real — cada ejecución de prueba consume tokens reales. Nos hemos establecido en una estrategia de pruebas determinísticas para la capa de orquestación y pruebas estadísticas para el comportamiento del agente, pero es insatisfactorio. El ciclo de retroalimentación es lento y los intervalos de confianza son amplios.

La observabilidad es primitiva. En un sistema multi-agente, las preguntas más importantes son: ¿qué agente consumió más tokens? ¿A dónde se fue el presupuesto? ¿Qué subtarea tomó más tiempo? ¿Fue eficiente la descomposición de tareas, o el agente líder creó subtareas redundantes? Hoy, responder estas preguntas requiere análisis manual de logs. No hay dashboard, no hay alertas y no hay optimización automatizada. Para equipos que ejecutan sistemas multi-agente a escala, esta es la brecha más urgente.

La predicción de costos es imposible. Puedes estimar el costo de una interacción con un solo agente con precisión razonable. No puedes estimar el costo de una tarea multi-agente antes de ejecutarla. El número de subtareas depende de la entrada. El consumo de tokens de cada subtarea depende de lo que el agente descubre durante la ejecución. El número de iteraciones de convergencia depende de si los sub-agentes producen resultados conflictivos. La varianza es demasiado alta para una predicción significativa, lo que hace que la presupuestación y fijación de precios sean extremadamente difíciles para servicios en producción.

Hacia dónde se dirige esto

La orquestación de agentes en 2026 se parece a los sistemas distribuidos en 2010. Los problemas son reales, las soluciones están emergiendo y las herramientas son primitivas pero mejoran rápidamente. Así como el mundo de los sistemas distribuidos eventualmente convergió en patrones estándar — service meshes, circuit breakers, trazado distribuido, orquestación de contenedores — el mundo de los agentes convergirá en patrones estándar para descomposición de tareas, gestión de contexto, aislamiento y convergencia.

Los frameworks que ganarán son los que traten estos patrones como preocupaciones de primera clase, no como ocurrencias tardías. DeerFlow es un ejemplo de un framework que hace esto bien. Habrá otros. La idea clave es que la orquestación multi-agente es un problema de infraestructura, no un problema de IA. Los modelos son lo suficientemente buenos. La orquestación no — todavía.

Si estás construyendo sistemas multi-agente hoy, nuestro consejo es simple: invierte en infraestructura de orquestación antes de invertir en agentes más inteligentes. Un sistema bien orquestado de agentes capaces superará a un sistema mal orquestado de agentes brillantes en todo momento. El cuello de botella no es la inteligencia. Es la coordinación.