Conductor propone multiagentes sin orquestador LLM: cuándo sí conviene un YAML determinista

Hay una costumbre que ya empieza a salir cara: poner un LLM también a decidir qué agente corre, en qué orden y con qué contexto, incluso cuando el workflow ya es bastante conocido. Eso puede servir en exploración. En operación repetible, muchas veces es una mala idea.

Por eso Conductor, publicado por Microsoft el 14 de mayo de 2026, me parece más interesante de lo que suena. La apuesta es muy concreta: definir flujos multiagente en YAML y dejar la orquestación fuera del bucle del modelo.

La propuesta en una línea

Conductor se presenta como un CLI open source para workflows multiagente donde:

• las rutas son deterministas;
• las condiciones usan Jinja2 y evaluación de expresiones;
• el workflow vive en YAML;
• y la capa de orquestación consume cero tokens.

Ese detalle parece pequeño, pero toca un problema real. Cuando el “coordinador” también es un LLM, pagas tres veces:

1. más costo por routing;
2. más latencia;
3. y más dificultad para repetir exactamente el mismo flujo.

Si el pipeline ya existe en tu cabeza o en un diagrama interno, muchas veces no necesitas otro agente pensando cómo caminarlo. Necesitas una ruta explícita, auditable y versionable.

Dónde sí tiene sentido

La propia nota de Microsoft da varios ejemplos: code review pipelines, research-then-synthesize y plan-then-implement. Yo sumaría otros casos parecidos:

• clasificación y handoff;
• verificación antes de ejecutar;
• approvals humanos en puntos concretos;
• y fan-out controlado sobre tareas paralelas.

Ahí lo importante no es “ser creativo”. Lo importante es no gastar contexto en decidir lo que ya sabes que debe pasar.

Lo fuerte no es el YAML; es lo que ese YAML obliga a aclarar

El README del repo deja ver por qué esta herramienta puede atraer tráfico bueno:

• ejecución paralela;
• composición de sub-workflows;
• pasos de script;
• pasos de set;
• límites de tiempo e iteraciones;
• human-in-the-loop;
• dashboard web;
• e inyección automática de AGENTS.md, CLAUDE.md y .github/copilot-instructions.md.

Eso empuja una disciplina útil: hacer explícito el contrato entre agentes, contexto y decisión.

Con demasiados frameworks, el contexto termina “sangrando” entre etapas. Un agente hereda ruido del anterior, la memoria se mezcla, y al final nadie entiende por qué se tomó cierta rama. Conductor intenta cortar esa ambigüedad desde el diseño.

La intención de búsqueda es bastante clara

Aquí no espero tráfico de curiosidad. Sí veo búsquedas cualificadas como:

• multi-agent workflow yaml
• deterministic orchestration agents
• conductor microsoft
• orquestacion multiagente
• human in the loop agent workflow

Esa gente ya no está preguntando “qué es un agente”. Está tratando de resolver cómo pasar de demos improvisadas a flujos repetibles que puedan vivir en CI, en un repo o en una operación interna.

En español todavía falta mucho contenido sobre esa capa intermedia. Hay material sobre frameworks gigantes o sobre prompts sueltos, pero poco sobre cómo declarar un workflow agentic sin delegar al modelo decisiones que deberían quedar fijas.

Qué haría antes de adoptarlo

No lo pondría en todos lados.

Si el problema es abierto y la secuencia depende del descubrimiento en tiempo real, una orquestación más dinámica puede seguir teniendo sentido. Conductor no intenta reemplazar eso. Intenta atacar los flujos donde el camino general ya es conocido.

Mi filtro sería este:

1. si el workflow puede dibujarse antes de correr, Conductor merece evaluación;
2. si necesitas repetirlo muchas veces y comparar corridas, gana más valor;
3. si además quieres revisión por PR del pipeline mismo, el YAML juega a favor.

Lo que más me gusta del enfoque

No vende magia. Vende una renuncia deliberada: sacar inteligencia probabilística de la capa donde más molesta cuando falla.

Eso es sano. En multiagentes, demasiados equipos intentan hacer “más inteligente” la parte que en realidad debería ser más predecible. Terminan pagando por routing, por retries raros y por bugs que casi no se pueden reproducir.

Conductor recuerda algo importante: a veces mejorar un sistema agentic no significa meter más modelo, sino decidir mejor dónde no hace falta modelo.

Si todavía estás ordenando la base antes de abrir workflows con varios agentes, el punto de entrada más simple sigue siendo el curso gratis. Y si te interesa la otra mitad del problema, esta noticia conversa bien con STATE-Bench y la memoria de agentes: una pieza intenta hacer más estable la ruta; la otra intenta medir si el agente mejora cuando ya lleva historia encima.