Deja que un agente de código dirija a los demás con Paneflow Conductor

Lanzar un agente de código es fácil. Lanzar varios en paralelo se convierte en un problema de coordinación: cuál está trabajando, cuál está esperando, qué rama está cambiando y qué resultado debe alimentar el siguiente paso.

Paneflow Conductor llega con Paneflow 0.6.0 para hacer explícita esa coordinación. Un agente puede descubrir a sus pares, leer su salida, enviar el siguiente prompt y esperar a que termine el turno mediante la CLI pública paneflow.

Una CLI para toda la flota

Todo pasa por el socket local de Paneflow. El conductor puede ser Claude Code, Codex, OpenCode, Gemini o un script, porque la interfaz son comandos de shell.

paneflow ps
paneflow status claude-impl
paneflow read claude-impl --lines 120
paneflow send claude-impl "Keep going and finish with REPORT_DONE"
paneflow wait --match claude-impl --pattern '^REPORT_DONE'
paneflow watch

Ese es el cambio importante. Codex puede inspeccionar lo que produjo Claude Code. Claude Code puede pasar una revisión a OpenCode. Un script puede iniciar el mismo workflow sin importar qué harness ejecuta cada panel.

Para trabajo repetible, paneflow up inicia un espacio de trabajo con hooks desde un archivo TOML, y paneflow flow run ejecuta una pipeline multiagente con spawn, espera, contexto y revisión.

Delegar sin ocultar las terminales

Paneflow Conductor no reemplaza a los agentes y no convierte Paneflow en un runtime hospedado. Los paneles siguen siendo terminales reales. Puedes leerlos, tomar el control, detener un comando o cambiar de dirección.

El valor está en que los agentes ya no necesitan contexto copiado y pegado. Un agente conductor puede leer un panel vecino, entender el estado actual, enviar un follow-up preciso y esperar una línea centinela como REPORT_DONE antes de continuar.

Ese patrón importa cuando separas implementación, revisión, tests y documentación. El agente líder no tiene que adivinar desde notas viejas. Puede inspeccionar la flota real.

Esperar estado, no temporizadores

Paneflow 0.6.0 añade una máquina de estados por turno para los agentes con hooks. Un panel puede reportar estados como thinking, waiting_for_input y finished. paneflow watch emite eventos de ciclo de vida como JSONL, y paneflow wait bloquea sobre una condición en lugar de dormir durante un retraso arbitrario.

Esa es la diferencia entre orquestación y screen scraping. Un conductor no debería consultar una terminal cada pocos segundos esperando que la salida se estabilice. Debería reaccionar cuando el agente se detiene de verdad, pide entrada o imprime el marcador prometido.

Mantener visible el límite de control

El modelo de seguridad es deliberado. El puente MCP es de solo lectura. paneflow read trata la salida de pares como datos no confiables. Por defecto, paneflow send pre-rellena un prompt y una persona sigue pulsando Enter.

Auto-submit existe, pero es opt-in mediante la puerta de scripting o el modo AI free access. Eso deja disponible el camino potente para worktrees aislados y workflows confiables, sin convertir las escrituras silenciosas entre paneles en el comportamiento por defecto.

Ese límite es el punto: dar a los agentes suficiente contexto compartido para trabajar juntos, mientras las terminales siguen visibles y la persona puede tomar el control.

Empezar con una flota pequeña

La referencia completa está en la documentación de Conductor. Empieza con dos paneles: un agente de implementación, un agente de revisión y un conductor que lee ambos antes de enviar el siguiente prompt.

Si ya ejecutas varios agentes CLI lado a lado, Paneflow Conductor les da una superficie común en lugar de otro protocolo privado.