Lanzar un sistema multi-agente no es lanzar un chatbot.

Cuando lanzamos la primera versión del orchestrator de GOGOGO, lo tratamos como un chatbot más inteligente. Un modelo, un system prompt largo, unas pocas tool calls. Funcionaba en demos. Colapsaba en producción. Tres reescrituras después, lo que tienes delante no es un chatbot — es un runtime. Y esa distinción es lo que marca la diferencia entre una feature y una capa operativa.

Qué se rompió en la v1

El primer orchestrator era un solo LLM con acceso a herramientas. Escribimos prompts que le pedían ‘decidir a qué especialista llamar’ y ‘pasar el contexto correcto’. Cada demo pasaba. Cada ejecución en producción era una moneda al aire. El modelo olvidaba qué especialista ya había llamado, repetía tool calls o — peor — re-ejecutaba llamadas con efectos secundarios porque perdía el rastro del grafo de la conversación.

La solución no era una ventana de contexto más grande. Fue admitir que el trabajo del orchestrator es estructural, no generativo.

Trata los hand-offs como un contrato tipado

En la v2 dejamos de permitir que el orchestrator escribiera sus propios payloads de hand-off. Cada hand-off es ahora un esquema tipado, validado en el borde del agent. Los especialistas no consumen lenguaje natural; consumen entrada estructurada y emiten salida estructurada. El único trabajo del orchestrator es elegir al siguiente especialista y enrutar el payload tipado.

// Hand-offs are values, not text.
type HandOff =
  | { to: "goddo.image.generate"; input: ImageRequest }
  | { to: "govista.schedule"; input: ScheduleRequest }
  | { to: "gopeople.classify"; input: ClassifyRequest }
  | { to: "gotrack.score"; input: ScoreRequest };

const next = orchestrator.decide(state);
assertHandOff(next); // throws on shape mismatch
await runtime.run(next);

Replay o no pasó

El mayor salto en confiabilidad vino de hacer reproducible cada ejecución. Cada paso persiste tres cosas: la entrada que recibió, la decisión que tomó y la salida que produjo. Con eso, depurar una ejecución fallida no es un ejercicio de intuición — es un diff entre la traza que funciona y la que está rota.

Qué significa realmente ‘replay’

• Re-ejecutar el mismo agent con la misma entrada y verificar que la salida sea estructuralmente equivalente.
• Sustituir un especialista por una nueva versión y reproducir la traza para detectar regresiones antes del deploy.
• Hacer rollback de un tenant al último grafo de orchestrator conocido como bueno reproduciendo sus últimas 24 h de ejecuciones contra él.

Las herramientas son el runtime, no el modelo

Solíamos pensar en las herramientas como ‘misiones secundarias’ que el modelo podía tomar opcionalmente. Marco equivocado. Las herramientas son el runtime. El modelo decide; las herramientas hacen el trabajo. Cuando nos apoyamos en eso, el orchestrator dejó de intentar ser inteligente respecto al estado y empezó a confiar en las herramientas como fuente de verdad.

Tres reglas con las que terminamos

1. Las herramientas son idempotentes o están etiquetadas. El orchestrator nunca reintenta una herramienta no idempotente sin política explícita.
2. Las herramientas son dueñas de sus propios reintentos. El orchestrator hace el hand-off y espera — no entra en loop sobre transportes inestables.
3. Las herramientas emiten eventos estructurados. Cada llamada exitosa o fallida es una fila en la traza, no una línea de log.

Qué haríamos diferente la próxima vez

Si empezáramos hoy, empezaríamos por la traza. Construir el timeline primero, los agents segundo, el orchestrator tercero. La razón: cada equipo que lanza un sistema multi-agente termina reconstruyendo la observabilidad — pero para entonces ya han horneado cinco formatos distintos en cinco especialistas distintos. Empieza por el riel; los agents seguirán.

“Un orchestrator no es un chatbot más inteligente. Es el runtime dentro del cual viven tus agents. Si no puedes reproducirlo, no es tuyo.”