El Orquestador: Por qué la Intención Debería Sobrevivir al Proceso

Las pilas actuales de agentes están invertidas. La superficie (terminal, editor) posee el modelo, las herramientas y el historial, mientras que la identidad es efímera: abre una nueva terminal y el agente desaparece. El autor propone una capa orquestadora que desacopla la intención de cualquier proceso individual. Propiedades clave:

• Identidad por encima de las sesiones: Un agente lógico persiste a través de los procesos. Las sesiones van y vienen; el agente permanece.
• Enrutamiento a través de superficies: El agente distribuye trabajo a diferentes máquinas (p. ej., caja de repos, caja de GPU, teléfono) sin tratarlas como no relacionadas.
• Primitiva de transferencia real: Un objeto tipado que lleva lo que se hizo, lo que está sin terminar, decisiones bloqueadas — no un historial de chat con pérdidas.
• Agentes pares, no subagentes: Dos agentes en contextos diferentes se coordinan mediante un plano de control que ninguno posee.
• Llamadas entre controladores: “Modelo barato resume, modelo caro actúa” es una primitiva, no ingeniería de prompts. El orquestador elige el runtime por paso según costo, latencia, capacidad.
• Superficies de aprobación que sobreviven: Si el agente pausa para aprobación y estás a tres husos horarios de distancia, la aprobación viaja hacia ti sin mantener vivo al agente.

Ejemplo Concreto: Triar un Test Inestable

Hoy abres tres terminales y pegas trazas de pila entre Claude, Gemini y Grok. El flujo deseado por el autor bajo una única intención del orquestador: “Tria este fallo intermitente, propón una corrección, consigue que sea revisada.”

• Ollama (local): Ingiere el log de test, elimina ruido, produce un resumen estructurado del fallo. Gratis, nunca sale de la máquina.
• Gemini CLI: Toma el resumen más el repositorio, identifica el cambio sospechoso, redacta un parche. Contexto grande, fuerte leyendo código, acceso de solo lectura al repo.
• Grok Build: Toma el parche y el fallo original, emite un veredicto (enviar/revisar/escalar). Otra familia de modelos como segunda opinión. Sin acceso de escritura.

Tres runtimes, tres ámbitos de permisos, tres niveles de costo, una intención. El orquestador lleva el objeto de transferencia entre pasos y presenta una única aprobación en lugar de tres conversaciones desconectadas. Si Grok dice “escalar”, la intención se pausa y espera una decisión humana — sin mantener vivos a Ollama o Gemini.

A partir de la semana pasada, al menos tres agentes de código nativos de terminal se ejecutan localmente: el runtime de Ollama, el CLI de Google Gemini y Grok Build de xAI con modo plan y subagentes paralelos. El modelo es la parte barata y reemplazable. El orquestador debería ser la parte aburrida y duradera.