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](https://github.com/ArthurDEV44/paneflow/releases/tag/v0.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.

```bash
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](/es/docs/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.