Microsoft Conductor y el determinismo en flujos agénticos (Parte I)

Con temperatura 0, el modelo elige en cada paso el token más probable. En teoría, eso hace la generación determinista. En la práctica, no.

Horace He y Thinking Machines Lab lo midieron en Defeating Nondeterminism in LLM Inference (10 de septiembre de 2025): 1000 respuestas al mismo prompt con temperatura 0 sobre Qwen3-235B dieron 80 respuestas distintas. La más frecuente apareció 78 veces y las divergencias empezaban en el token 103. La causa es aritmética: la suma en coma flotante no es asociativa, y los kernels de inferencia cambian el orden de las operaciones según el tamaño del lote, que depende de la carga del servidor. Quien llama obtiene un resultado que depende de algo que no controla. Con kernels invariantes al lote, los autores consiguieron 1000 respuestas idénticas, a cambio de una inferencia más lenta.

Los proveedores lo reconocen. OpenAI ofrece seed y system_fingerprint para mejorar la reproducibilidad, pero no la garantiza (OpenAI Cookbook). Azure OpenAI dice lo mismo y añade que la variabilidad crece con respuestas más largas (Microsoft Learn). Y en un servicio gestionado no controlamos ni los kernels ni el lote.

• Sensibilidad a la entrada. Un cambio mínimo en el contexto (un fichero más, otro orden, una línea de log) puede cambiar la respuesta de forma desproporcionada, y en un sistema real el contexto casi nunca se repite.
• El modelo cambia. Versiones nuevas, alias que apuntan a otro modelo, cambios de infraestructura. Un prompt que hoy funciona puede fallar dentro de tres meses sin que hayamos tocado nada.
• Determinismo no es corrección. Un modelo determinista que se equivoca se equivoca siempre igual. La reproducibilidad ayuda a depurar, no a acertar.

Un agente encadena muchas llamadas, y cada una depende de las anteriores. Si en el primer paso lee otro fichero, todo lo demás parte de otro contexto, y una divergencia pequeña acaba en una trayectoria distinta. En una cadena de agentes, el efecto se multiplica en cada frontera.

Empeora mucho si el propio modelo decide qué paso es el siguiente. Si un LLM hace de orquestador («ahora llama al revisor», «esto ya está»), la variabilidad pasa del contenido a la estructura: qué se ejecuta, cuántas veces y cuándo se para. Ya no tenemos un proceso con partes variables. Tenemos un proceso variable.

La conclusión no es que los LLM no sirvan. Es que su variabilidad no se elimina: se acota, y para eso hace falta algo predecible a su alrededor.

Hay piezas que no deberían depender nunca de un modelo:

• El grafo: qué pasos existen y en qué orden.
• Las transiciones: se deciden con condiciones sobre datos, no con una frase del agente.
• Los contratos: qué entra en cada paso y qué forma tiene lo que sale. Lo que no cumple el contrato no avanza.
• La verificación objetiva: compilar, ejecutar los tests, pasar el linter. A un agente no se le pregunta si los tests pasan: se ejecutan.
• Las condiciones de parada: iteraciones, tiempo y coste. Un bucle sin límite es un fallo esperando a ocurrir.
• Los resultados finales: cómo terminó el proceso en términos de negocio, no del motor.

Que el grafo llegue al final sin excepciones no dice si el artefacto existe, si es válido o si alguien lo aceptó. Cada camino debería terminar en un resultado explícito: aceptado, rechazado, bloqueado, no materializable. El final genérico del motor es un detalle de implementación. El negocio necesita saber cómo acabó.

En los componentes deterministas esperamos el mismo resultado ante la misma entrada, y lo comprobamos con tests convencionales. En los probabilistas verificamos la envolvente (que la salida respeta el contrato, que el flujo no se sale del grafo, que los límites se cumplen) y medimos propiedades con evals, frente a un umbral declarado de antemano. No buscamos un sistema perfecto, sino uno observable, falsable y contrastable con contratos explícitos.

Que el flujo sea determinista no significa que el orquestador decida qué es «listo para desarrollo» o si una transición de estado es legal. Esas reglas son del dominio. El reparto que me funciona:

• El dominio define el significado y la legalidad.
• El orquestador ejecuta la secuencia y aplica los límites.
• Los scripts hacen las mutaciones deterministas.
• Los agentes resuelven decisiones semánticas acotadas.
• Las personas resuelven lo que no se puede mecanizar.

Disclaimer

Los detalles sobre Conductor y el ejemplo corresponden a la versión 0.1.42 (octubre de 2026). El proyecto evoluciona rápido, así que conviene contrastarlos con la documentación actual.

Nota sobre el uso de IA: redactado con ayuda de herramientas de inteligencia artificial, a partir de la experiencia, las ideas y el criterio del autor, que ha dirigido, revisado y validado todo el contenido. Las opiniones, el análisis y las reflexiones son del autor.

1. Microsoft Conductor: github.com/microsoft/conductor (README, docs/workflow-syntax.md, src/conductor/engine/router.py, src/conductor/engine/limits.py, src/conductor/engine/workflow.py, src/conductor/gates/human.py, src/conductor/config/schema.py, src/conductor/engine/context.py, release v0.1.42, 6 de octubre de 2026).
2. Horace He y Thinking Machines Lab, Defeating Nondeterminism in LLM Inference, 10 de septiembre de 2025.
3. OpenAI Cookbook, How to make your completions outputs reproducible with the new seed parameter.
4. Microsoft Learn, Reproducible output (Azure OpenAI).