Orquestación

Un solo agente es bueno en una sola cosa. Algunas peticiones son más grandes que eso: «investiga el mercado de X y escribe un documento de posicionamiento», «entrega esta funcionalidad de principio a fin», «audita este módulo y corrige lo que encuentres». Una orquestación es la forma en que Control Center gestiona esas peticiones: un orquestador (normalmente tu agente CEO) propone un plan de todo el equipo, tú lo apruebas una sola vez y un materializador determinista lo convierte en un pipeline que hace el trabajo.

Se sitúa entre las dos formas que ya existen de sacar el trabajo adelante:

Cuando quieres…	Usa
Encargar una tarea a un agente	Un mensaje en un espacio
Codificar a mano un proceso que ya conoces	Una plantilla de pipeline
Decir el objetivo y dejar que el equipo averigüe el plan	Una orquestación

La forma de una propuesta

Cuando le das un objetivo al orquestador, este devuelve un OrchestrationProposal estructurado: un plan tipado que la aplicación puede validar y ejecutar, en lugar de prosa libre. Una propuesta tiene:

Objetivo: tu petición de alto nivel, reformulada.
Roles: quién hace el trabajo. Cada rol es un agente existente que eliges tú o una nueva contratación que la orquestación crea al aprobarse.
Subtickets: el trabajo, desglosado en un DAG de tickets.
Investigación (opcional): una fase de investigación que se ejecuta primero y alimenta al resto.
Debate (opcional): una ronda acotada en la que cada rol publica una postura estructurada antes de que empiece el trabajo.
Síntesis: el paso final que produce el entregable.
Presupuesto: un techo de coste declarado.

Dónde lo revisas

Dos superficies muestran la misma orquestación.

La tarjeta de propuesta vive en la conversación que produjo el plan. Es un único mensaje que se vuelve a renderizar a lo largo de todo el ciclo de vida —propuesto, en ejecución, completado— con las acciones de aprobar y cancelar sobre él.

Plan Studio es el editor: un lienzo de DAG, un inspector de nodos, un cajón de revisiones y diferencias y la barra de aprobación que lleva la estimación. Se abre como una pestaña de editor directamente desde esa tarjeta. Deliberadamente no hay ningún elemento «Planes» en la barra lateral; /plans y /plans/:kind/:id existen como enlaces profundos para compartir.

Aprobar es competencia exclusiva del operador. No hay ninguna herramienta MCP para ello: un agente puede proponer (propose_orchestration), enviar un plan (submit_plan) o instanciar un playbook (run_playbook), pero solo una persona aprueba. Además, las revisiones iniciadas por un agente están limitadas por un enfriamiento de dos minutos, de modo que un bucle de replanificación se agrupa en lugar de inundar tu flujo.

Lo que puedes cambiar antes de aprobar es lo que expone el inspector de nodos: cambiar el título o reescribir un subticket, cambiar qué rol lo posee, recablear sus dependencias, editar su esquema de salida o eliminar el nodo directamente. Los nodos estructurales (investigación, debate y síntesis) y los nodos que ya se han ejecutado son de solo lectura. No puedes fijar un rol a un agente concreto ni puedes editar el presupuesto desde el editor.

Que dos editores trabajen sobre un mismo plan se resuelve con concurrencia optimista, no fusionando. Cada edición lleva la base_revision sobre la que se hizo; una edición basada en una revisión obsoleta se rechaza con «el plan ha avanzado» en lugar de pisar en silencio la de otra persona. Rebobinar tampoco es eliminar: añade la propuesta anterior como una revisión nueva, así que la línea temporal de revisiones solo crece.

Estimaciones honestas, o ninguna

La estimación de la barra de aprobación se construye a partir del historial real de ejecuciones completadas de cada rol, como una banda intercuartílica (p25–p75). Los totales de coste suman los nodos estimables; la duración es la ruta crítica a través del DAG en lugar de la suma (las ramas paralelas se solapan).

Un nodo cuyo rol no tiene ningún historial de ejecuciones completadas informa de sampleSize: 0 y rangos nulos. Eso se muestra exactamente así —desconocido—, nunca como un valor puntual inventado, porque una estimación en la que no puedes confiar es peor que ninguna estimación. Cuando algunos nodos tienen historial y otros no, el total se marca como parcial. El radio de impacto solo aparece cuando un nodo ha declarado referencias de procedencia symbol o file; un nodo sin ellas se queda en «desconocido» en lugar de inferirlo a partir de la prosa.

Una aprobación y después una ejecución determinista

Esta es la idea central: el agente planifica; una función determinista ejecuta. Cuando apruebas, OrchestrationMaterializer, una función pura sin LLM y sin E/S, convierte la propuesta en un pipeline real. Dados la misma propuesta y los mismos roles resueltos, siempre produce el mismo DAG. Eso importa porque el pipeline generado hereda todo lo que el motor ya hace gratis: suspensión y reanudación entre reinicios, recuperación tras fallos, acumulados de coste y tokens por ejecución y la interfaz de detalle de ejecución.

La aprobación también crea el andamiaje que el trabajo necesita:

contrata cualquier rol marcado como nuevo (y registra los identificadores de los agentes contratados para que un fallo a mitad de aprobación pueda reanudarse sin contrataciones duplicadas)
un equipo que agrupa los roles
un proyecto en el que se archiva el ticket principal
la plantilla de pipeline + la ejecución que lo impulsa todo

El ciclo de vida

proposed → approved → executing → synthesizing → completed
                  ↘                 ↘              failed
                   ↘                 ↘            cancelled

Estado	Significado
`proposed`	El plan está listo y esperando tu única aprobación inicial
`approved`	Lo aprobaste; la materialización está en curso (contrataciones, equipo, proyecto, pipeline)
`executing`	El pipeline generado se está ejecutando: subtickets, debate, trabajo
`synthesizing`	Los subtickets han terminado; el paso de síntesis está produciendo el entregable
`completed`	Hecho: el ticket principal se marca como completado y el entregable se publica en el espacio compartido
`failed`	La materialización falló, o falló la ejecución del pipeline generado
`cancelled`	Lo cancelaste

Un número de revisión monotónico sigue la propuesta mientras el orquestador la revisa y esta todavía está en proposed; la aplicación registra qué revisión aprobaste. propose_orchestration rechaza una revisión en cuanto el estado deja de ser proposed.

Una orquestación siempre se abre contra un ticket principal y comparte un único espacio de debate, de modo que todo el esfuerzo es trazable hasta un solo elemento de trabajo y el equipo habla en una única sala.

Qué ocurre cuando termina

Un escucha que se mantiene vivo observa el pipeline generado y traslada su estado terminal de vuelta a la orquestación y al ticket principal, de modo que la finalización y el fallo afloran en los sitios que ya vigilas. La función de orquestación no necesita su propio motor de ejecución.

Puedes cancelar una orquestación en cualquier momento; la cancelación desmonta el trabajo en curso.

Véase también

Pipelines y automatización: el motor sobre el que se ejecuta una orquestación materializada
Tickets y delegación: el ticket principal sobre el que se ancla una orquestación
El modelo de agentes: los roles que una orquestación cubre o contrata
Ejecutar una orquestación
Trabajar en Plan Studio