El metaorquestador es la mesa de trabajo

Este reporte describe una ejecución interna anonimizada de agosto de 2026. “Multislice” significa unidades de trabajo definidas en el gestor —API, UI, cumplimiento, documentación y limpieza—, no un conteo de agentes activos al mismo tiempo. Eliminamos identificadores de clientes, superficies específicas del sector, rutas, texto de incidencias, conteos exactos de incidentes y metadatos de cuentas. Las observaciones restantes son evidencia propia, no resultados de un benchmark.

Usamos Orca para llevar un rediseño de espacio de trabajo a través de un monorepo de una industria regulada. En el punto de mayor actividad, trabajadores de Claude, Codex, OMP y Pi implementaban slices de API, UI, cumplimiento, documentación y limpieza al mismo tiempo. El espectáculo visible era la flota. El sistema útil era lo que evitaba que los trabajadores se convirtieran en conversaciones sin relación.

El coordinador convirtió el gestor en un grafo ejecutable de dependencias, redactó contratos con límites exactos, asignó trabajo a herramientas y modelos compatibles, observó señales de terminación, resolvió preguntas y alimentó las ramas terminadas a una cola serial de integración. Los trabajadores no poseían el plan global. El coordinador no microgestionaba su implementación local. Esa separación permitió avanzar rápido sin dejar que el contexto local redefiniera el alcance.

La concurrencia es un recurso, no una estrategia. Iniciar doce agentes es fácil. Preservar un contrato de producto entre doce vistas parciales e integrar sus resultados sin perder evidencia es el verdadero trabajo de ingeniería.

Orca nos dio un vocabulario que sobrevivió al cambio de terminales y a las interrupciones de la máquina. Un Run era el objetivo durable y el inbox del coordinador. Una Task era una unidad de trabajo con dependencias y estado. Un Dispatch era un intento concreto de un worker en una terminal o worktree. Mantener esas identidades separadas importó cuando un agente se detuvo, una terminal reinició o una rama necesitó un revisor de reemplazo.

La señal de terminación del worker no era un mensaje decorativo. Llevaba identidad de Task y Dispatch, outcome, archivos tocados, hallazgos y trabajo restante. Las preguntas regresaban al coordinador en lugar de ser contestadas con suposiciones. Un intento fallido podía reemplazarse sin fingir que la Task había tenido éxito. Esto permitió recuperar después de interrupciones de la estación de trabajo: pudimos releer y reconciliar el filesystem, las ramas, los pull requests, el tracker y los recibos de orquestación en lugar de reconstruirlos de memoria.

La lección práctica es más amplia que Orca. Un meta-orquestador necesita identificadores durables, inbox, transiciones explícitas de lifecycle y recuperación idempotente. Una cuadrícula de terminales es una interfaz. Todavía no es un plano de control.

En esta ejecución asignamos Fable 5 a coordinación amplia y síntesis de contexto largo, modelos GPT a implementación delimitada, revisión adversarial y refactors exactos, y Kimi K3 a una lectura estructural independiente. Fueron asignaciones observadas, no capacidades permanentes de una familia. Las reevaluamos contra el catálogo vigente y la forma de falla esperada. OMP hizo portables esas asignaciones mediante una superficie común, selectores vivos, kernels persistentes, LSP, subagentes y cadenas de fallback configuradas por modelo y rol.

La regla de enrutamiento seguía la forma de la tarea. Carriles rápidos manejaban inventario, verificaciones mecánicas y limpieza acotada. Carriles de razonamiento fuerte manejaban arquitectura, seguridad, conflictos de migraciones y síntesis final. La revisión usaba diversidad intencional: confianza correlacionada no es evidencia independiente. Cuando los modelos coincidían buscábamos la base factual común; cuando diferían, el desacuerdo se convertía en una decisión explícita.

La herramienta también formaba parte del enrutamiento. Claude Code, Codex CLI, Pi, OMP y otros agentes difieren en contratos de herramientas, confiabilidad de edición, manejo de contexto, conducta de revisión y acceso a proveedores. Orca los trató como trabajadores detrás de un ciclo de vida. El metaorquestador preservó el contrato mientras elegía la ruta confiable de menor costo. Sólo permitimos cambiar de proveedor o modelo cuando la clasificación y la política de retención del artefacto lo autorizaban.

Las flotas reales fallan de manera desigual. Expiran credenciales. Una ruta acepta un probe pequeño y rechaza el prompt real. Un harness inicia con el runtime equivocado. Un testbox remoto carece del package manager esperado. Un revisor llega al rate limit después de que la implementación terminó. Durante esta ejecución encontramos esas formas, además de interrupciones de la estación de trabajo y una verificación baseline del repositorio que ya estaba rota antes de que varias ramas comenzaran.

La respuesta útil fue una escalera: reintentar la misma ruta sólo para una falla transitoria y acotada; cambiar de proveedor para el mismo modelo cuando el transporte es el problema; cambiar de modelo en el mismo harness cuando cambian capacidad o disponibilidad; cambiar de harness cuando falla su superficie de herramientas; mover ejecución a otra máquina cuando falla el entorno; escalar a una persona cuando autoridad, ambigüedad o riesgo exceden el límite delegado. Cada peldaño conservó Task, pruebas, review, privacidad y auditoría originales. El baseline rojo tenía un dueño nombrado; los slices afectados usaron gates acotados y delta-green para que ninguna rama agregara fallas mientras la reparación raíz avanzaba por separado.

Un mal fallback baja el estándar silenciosamente: omite el review, reduce la prueba, acepta una rama obsoleta o llama completo a un artefacto parcial. Un buen fallback preserva la semántica y cambia sólo los medios. Por eso la política de fallback pertenece al orquestador y no a prompts improvisados.

La implementación paralela avanzó más rápido que la integración del estado compartido. Chocaron números de migraciones. Ramas de UI tocaron los mismos barrels y registros de traducción. Una rama verde contra el head de ayer quedó en conflicto después de integrar tres prerequisitos. La flota seguía siendo productiva, pero el camino crítico se había movido de generación a integración.

Respondimos serializando el límite peligroso. Los workers continuaron en paralelo sobre slices independientes, mientras un solo dueño de integración para esta ejecución hacía rebase, conciliaba migraciones, repetía gates relevantes y avanzaba la rama compartida un pull request a la vez. Las tareas downstream siguieron bloqueadas hasta que su prerequisito real aterrizó; no bastó con que un worker anunciara que su rama estaba lista. La regla general es un solo responsable de escritura cercado a la vez por cada superficie disputada, no una persona permanente ni una cola global.

La regla de diseño es un único responsable de escritura por cada fuente de verdad disputada. Muchos trabajadores pueden proponer cambios. Una cola posee la rama compartida. Una secuencia posee el orden de migraciones. Un gestor posee el estado de entrega. Un registro posee la configuración de modelos o funciones. El rendimiento sale de paralelizar lo independiente y serializar deliberadamente lo que no lo es.

El coordinador nunca trató el resumen confiado de un worker como terminación. Un slice avanzaba sólo cuando existía el artefacto, el path cambiado había sido ejercitado, los checks requeridos pasaban sobre el head actual, reviews independientes estaban conciliados, los threads estaban resueltos y Linear reflejaba el mismo estado que el repositorio. Cuando un servicio obligatorio de review llegó al rate limit, la tarea esperó o usó un gate equivalente aprobado; ausencia de revisor no se convirtió en aprobación.

Esto produjo una asimetría útil. Los workers podían ser creativos dentro de sus slices, pero terminar era aburrido y mecánico. La prueba dependía de la tarea: un bug necesitaba una reproducción que ya no fallara; un cambio UI necesitaba un path visual operado; un contrato API necesitaba pruebas enfocadas y una llamada smoke; un merge necesitaba CI sobre el head actual y review limpio. La evidencia se generó después del cambio relevante, no se heredó de un head anterior.

Los recibos también hicieron posible una recuperación honesta. Después de una interrupción no preguntamos qué agente sonaba terminado. Preguntamos qué Tasks tenían Dispatches concluidos, qué pull requests eran integrables, qué comprobaciones estaban verdes, qué hilos seguían abiertos y qué estados del gestor contradecían al código. Ningún sistema poseía toda la verdad: el gestor poseía la intención, Run/Task/Dispatch el ciclo de los intentos, la rama autoritativa los artefactos integrados, CI sobre el head actual la verificación y el sistema de revisión las objeciones y aprobaciones. Ante un desacuerdo detuvimos la promoción, reconciliamos con el dueño de ese hecho y generamos evidencia fresca.

La ruta práctica de adopción es pequeña. Primero elige una fuente de verdad de producto y convierte unas cuantas issues independientes en Tasks con criterios explícitos. Segundo crea un Run y asigna dos implementadores más un revisor independiente. Tercero exige terminación estructurada y conserva una cola de integración propiedad de un humano o coordinador. Cuarto agrega fallbacks de modelos y proveedores sólo después de poder identificar qué capa falló.

Los carriles adicionales no son gratuitos. Para una o dos tareas independientes de bajo riesgo, un solo trabajador fuerte con verificación enfocada suele ser más barato y fácil de coordinar. Agrega trabajadores heterogéneos cuando la especialización o el paralelismo acorten el camino crítico; reserva paneles multimodelo para artefactos importantes donde una falla no detectada cueste más que las llamadas y el tiempo de síntesis. Recalcula ese punto de equilibrio con precios, rate limits y carga del coordinador actuales, en vez de asumir que una flota siempre gana.

Este recorrido fue verificado con Orca 1.4.168, donde Orchestration es una función Experimental. Activa Settings → Experimental → Orchestration, carga la guía correspondiente a la versión del binario y confirma el estado del runtime. Si la función no existe, detente en lugar de traducir flags recordados. Construye el DAG antes de iniciar trabajadores. Lanza la wave lista sólo hasta el límite impuesto por la máquina, los proveedores y la capacidad del coordinador. Usa comprobaciones bloqueantes de delivery en lugar de observar terminales. En OMP, nombra carriles explícitos y guarda las cadenas de fallback en configuración.

Escala el ancho sólo cuando el coordinador pueda responder cinco preguntas: ¿Qué está listo? ¿Qué está bloqueado y por cuál dependencia integrada? ¿Quién posee cada superficie disputada? ¿Qué evidencia fresca se necesita? ¿Qué sistema posee el hecho en disputa? Si las respuestas no son inmediatas, más agentes aumentan trabajo en proceso más rápido que valor entregado. El metaorquestador es la mesa de trabajo donde la intención se convierte en concurrencia controlada y ésta en evidencia integrada.