Orquestación de agentes

Cada stage puede delegar su redacción a un agente especialista, y recurre al comportamiento integrado cuando no hay ninguno instalado, que es lo que mantiene a flow portable en lugar de dependiente del registro de agentes de otro. La escalera de prioridad es agentes especialistas primero, luego skills equivalentes, luego el fallback integrado. El mapa de stages es más o menos el esperado: research a un investigador, scope y PRD a un planificador, ADR a un arquitecto, contrato a un núcleo orientado a especificación, build a un desarrollador full-stack, review a un revisor de código o una revisión adversarial de tres capas, verificación en vivo a un tester.

La regla que hace esto seguro es una frase: los agentes son intercambiables, los gates son fijos. El gate es idéntico en todos los caminos, así que un agente ausente nunca puede bajar el listón y un agente sofisticado nunca puede aprobar lo que no ganó. La delegación también está aislada por diseño — un subagente recibe solo su tarea, sus archivos, sus criterios de aceptación y los extractos relevantes de ley o contrato, nunca el historial de la sesión — y devuelve uno de un conjunto pequeño de veredictos: DONE, DONE_WITH_CONCERNS, BLOCKED, NEEDS_CONTEXT. Después de cualquier delegación el gate se ejecuta, el desafío semántico se aplica, el hook durable se escribe, y se anuncia qué camino realmente corrió.

Esta página es el home del operador para la superficie de potencia alrededor de esa regla: un worktree por agente, motores extra opcionales, el ciclo recall/promote, y recibos ligados a huellas. Los diagramas del mantenedor quedan en el repo; solo se enlazan en el pie.

Workspace multi-agente

Varios agentes en varias terminales sobre un checkout es la trampa: uno de ellos cambia de rama, y todas las demás terminales cambian con él. /flow workspace da a cada agente su propio git worktree — propio HEAD, propio índice, propios archivos, almacén de objetos compartido — para que eso no ocurra.

/flow workspace add <branch>
/flow workspace add <branch> --card C-NNN --vendor <name> --task "<one line>" --copy-env
/flow workspace list
/flow workspace enter <branch>
/flow workspace check <branch> --card C-NNN
/flow workspace remove <branch>
/flow workspace doctor

• add <branch> crea el árbol con un offset de puerto distinto (para que dos servidores locales no colisionen) e imprime un bloque de cd y env listo para pegar. Los flags opcionales fijan una card, una etiqueta de proveedor, una línea de tarea, y si copiar el env al nuevo árbol.
• list muestra quién está dónde.
• enter <branch> reimprime el entorno para una terminal caída.
• check <branch> --card marca un choque de reclamación de rama y solapamiento de archivos permitidos antes de lanzar. Ejecútalo. Un conflicto de fusión posterior significa que esa comprobación se saltó o se manipuló.
• remove desmonta el árbol y nunca fuerza automáticamente. Si git se niega, lo resuelves tú; flow no hará --force por ti.
• doctor reconcilia árboles huérfanos y registros.

git mismo es el registro y el candado real. git worktree list está en vivo; la negativa de git a hacer checkout de una rama dos veces es lo que realmente te protege. El archivo lateral .flow/workspaces.jsonl solo añade metadatos de proveedor, card, puerto y tarea encima.

Usa estos verbos para que el journal no tenga huecos. Un git worktree add crudo no registra nada.

Segundo motor

OpenAI Codex (el plugin openai-codex) es un segundo motor opcional. Google Antigravity (el CLI agy o el IDE Antigravity) es un tercer motor opcional. Ambos son proveedores extra usados en los mismos momentos de alto valor para que una revisión pueda ser juzgada por modelos que rara vez comparten un punto ciego. Ninguno reemplaza la escalera especialista → skill → integrado. El motor por defecto sigue siendo esa escalera. La ausencia de Codex o Antigravity nunca rompe una ejecución.

flow distingue instalado de utilizable. Instalado significa que el plugin, binario o directorio del IDE está presente. Utilizable además requiere una sonda barata no facturable de que el motor está realmente listo y con sesión iniciada. Solo un motor utilizable recibe enrutado. Si no, flow degrada de forma silenciosa-pero-anunciada a la escalera normal, y el gate no se mueve.

Antigravity recibe la sonda más estricta de los dos, por una razón medida: agy -p devuelve código de salida 0 con stdout vacío incluso cuando no has iniciado sesión — el error solo aterriza en el archivo de log. Así que flow enruta a Antigravity solo con salida esperada no vacía, nunca con el código de salida, que miente. La captura headless no es fiable en esa plataforma, así que el valor por defecto soportado es interactivo: ejecuta la revisión en el IDE Agent Manager o una terminal real y pega el resultado de vuelta. Un resultado Gemini vacío significa «revisión no disponible» y nunca es una aprobación.

Como estas llamadas son facturables y porque el diff más extractos del contrato o PRD salen de la máquina, exactamente tres disparadores abren la compuerta del coste:

1. Un deadlock de dos strikes — un agente del mismo modelo bloqueado dos veces. Antigravity es el motor extra posterior: se dispara aquí después de Codex si tanto el camino del mismo modelo como el segundo motor se atascan.
2. Una revisión de card de clase de seguridad.
3. Un opt-in explícito del operador («revisa esto en Codex», «revisa esto en Antigravity», /flow … codex, /flow … antigravity).

Nunca en cada stage por defecto. Para un código sensible, regulado o bajo NDA, haz opt-in con conocimiento: elegir Codex envía ese resumen a OpenAI bajo los términos de retención de tu plan; elegir Antigravity lo envía a Google bajo tu plan de Gemini. La autenticación se delega por completo al plugin o a agy / el IDE. flow nunca lee, almacena ni registra esas credenciales.

La paridad de gates es absoluta. Codex o Antigravity redactan o critican; el gate de stage idéntico sigue juzgando. Una revisión entre modelos informa el triaje. Nunca aprueba ni suspende automáticamente una card.

Después de un uso, flow anuncia qué motor corrió (o que el nivel no estaba disponible y a qué degradó). Una ejecución sigue siendo legible.

Ciclo de conocimiento

Una ventana de conversación olvida. El harness durable — un almacén SQLite más RETRO.md, DEBT.md y playbooks/ — es un ciclo cerrado de captura, reutilización y mejora, para que un proyecto dirigido por agentes acumule experiencia como un equipo humano.

La captura la dispara el motor, no es voluntaria:

• avanzar más allá del stage 01 siembra un intake
• una comprobación de card que pasa registra una traza con nivel
• un skip deliberado registra su deuda

La reutilización es /flow recall. Ejecútalo al inicio de un stage o una card, antes de redactar nada. Lee de vuelta la deuda abierta, la retro más reciente, el alcance de la card anterior, la fricción y el backlog del harness, la salud de la auditoría y cualquier playbook promovido, para que el trabajo empiece con el dolor previo a la vista en lugar de redescubrirlo.

La mejora también es mecánica: harness audit puntúa entropía y deriva, harness propose mina la fricción repetida en un backlog de mejora una vez que un patrón se dispara al menos dos veces, y harness decision outcome cierra el ciclo predicho-versus-real.

El ritual de mitad de proyecto que empieza con resume y luego recall está en Retomar a mitad de proyecto.

Promote

Cuando una lección es más grande que un proyecto, elévala:

/flow promote <playbook.md>

Eso copia el playbook a la base de conocimiento entre proyectos en ~/.claude/flow/playbooks. Desde entonces, recall lo muestra en todas partes en lugar de solo donde se aprendió.

Ejecución atestada

Una vez que una ejecución es autónoma, «esto fue revisado» tiene que significar algo que un script pueda comprobar. El plano de control de ejecución atestada emite recibos ligados a huellas — un recibo semantic_gate para un stage o card revisado, un recibo live_verify para un despliegue comprobado — ligados a huellas de lo que aprobaron.

/flow attest semantic --stage <stage> --revision <rev> --owner <manifest>
/flow attest semantic --card <id> --base <rev> --revision <rev> --owner <manifest>
/flow attest live-verify <id> --revision <rev> --owner <manifest>
/flow attest status [<stage|card>]
/flow attest recover <C-NNN> --mark-failed

Acuñar se ejecuta contra blobs con commit en una revisión específica, no contra lo que esté sucio en el árbol de trabajo. Un recibo en vivo requiere la punta exacta de HEAD más huellas recomputadas, así que editar un archivo después de la aprobación invalida la aprobación en lugar de heredarla en silencio. status te dice si un recibo está vigente. recover … --mark-failed es el escape Must-ask cuando una verificación en vivo se atasca a mitad de vuelo; marca ese intento como fallido, no acuña un pase.

Mientras /flow auto está activo, check, el flip de card propiedad del CLI, la preparación de dependencias y eliminar un worktree fusionado requieren recibos vigentes. /flow auto stop te devuelve al modo manual solo-advertencias. No hay bypass oculto. Las reglas de halt de auto — incluyendo HALT de clase de seguridad — están en Cuándo detenerse.

Los recibos detectan obsolescencia del sujeto. No autentican actores y no resisten un host hostil. Son una guarda contra un ciclo autónomo que consume su propia aprobación desactualizada, no un límite de seguridad contra alguien con control de la máquina.

---

Homes del mantenedor (no la página pública): skills/flow/SKILL.md, skills/flow/references/codex-integration.md, skills/flow/references/antigravity-integration.md, skills/flow/references/attestations.md. Diagramas que necesita el mantenedor: docs/system-architecture.md.