Orquestación de un stack CLI multiagente: OpenCode, Cursor, agy, Copilot, Orca y OpenSpec

La mayoría de los equipos de ingeniería que exploran el desarrollo de código multiagente cometen un error costoso: tratan a distintos agentes de código como asistentes intercambiables. Cuando un ingeniero abre un ticket, le asignan todo el problema a un solo modelo. Ese modelo busca en el código heredado, escribe especificaciones, refactoriza ASTs, ejecuta pruebas y redacta pull requests.

Este enfoque sin segmentación produce fallas previsibles. Los equipos enfrentan costos de tokens descontrolados y ventanas de contexto contaminadas. Los modelos entran en bucles de alucinación en los que aprueban su propia lógica defectuosa. Mientras tanto, los workers concurrentes generan conflictos de merge en Git.

El August 21, 2026, exploramos una hipótesis arquitectónica y un diseño especulativo para coordinar un stack de agentes de código CLI seleccionado con criterios concretos: OpenCode (Claude Opus 5 High, 1M de contexto), Cursor Agent (Claude Opus 5 Max), agy (Gemini 3.7 Flash High) y GitHub Copilot (GPT-5.6 Sol Medium). Analizamos cómo orquestar estas herramientas mediante Orca (nuestro runtime de referencia para la ejecución de DAGs), junto con especificaciones de OpenSpec y GitHub Spec Kit y triaje brownfield en Jira.

[!NOTE] Hipótesis arquitectónica y advertencia: Esta guía presenta una hipótesis exploratoria y un análisis especulativo de sistemas, basados en una selección de agentes CLI, modelos de frontera y patrones de orquestación. Refleja una investigación de diseño sobre cómo estructurar herramientas emergentes para desarrolladores en pipelines de ingeniería multiagente resilientes; no es un estándar oficial de ningún proveedor.

Audiencia: Dirigido a ingenieros y arquitectos que desarrollan pipelines de agentes de código autónomos, equipos de plataforma y líderes técnicos que pasan de prompts individuales a sistemas multiagente.

Resumen

• Divide el monolito: Nunca permitas que un solo agente sea responsable de una tarea de principio a fin. Separa el flujo de trabajo en plano de control (OpenCode / Opus 5 High), plano de ejecución (runtime de Orca), workers de exploración (agy / Gemini 3.7 Flash), refactorización compleja (Cursor / Opus 5 Max) y revisión independiente (Copilot / GPT-5.6 Sol).
• La escala de escalamiento económico: La lectura, la búsqueda, la arqueología de código y la ejecución de pruebas representan el 70% de la ingeniería brownfield. Dirige estos pasos de alto volumen a modelos ultrarrápidos y económicos (Gemini 3.7 Flash mediante agy). Reserva el razonamiento de frontera (Opus 5 High/Max) para el diseño de sistemas, las especificaciones delta y la refactorización compleja de código.
• Dos topologías de pods: Separa los pods de triaje de solo lectura (para investigar issues, revisar el historial de Git y analizar causas raíz) de los pods de implementación con escritura aislada (que se ejecutan en worktrees de Git dedicados y tienen controles automatizados de pruebas).
• Artefactos como contratos: Los prompts en lenguaje natural son demasiado imprecisos para transferir tareas entre agentes. Usa especificaciones delta de OpenSpec, artefactos de Spec Kit y un contrato de tarea para agentes normalizado y legible por máquina (JSON/YAML) para definir entradas, ámbitos de escritura de archivos, comandos de prueba y límites de reintentos.
• Revisión entre modelos: Nunca permitas que un modelo de implementación evalúe su propio trabajo. Una refactorización generada por Opus debe ser revisada por un modelo GPT-5.6 Sol independiente para detectar puntos ciegos.
• Control de preparación de Jira: Nunca permitas que un issue de Jira active ediciones directas de código. Ejecuta una fase automatizada de recopilación de evidencia que calcule una puntuación de preparación del issue antes de iniciar un pod de implementación.
• Primitivas autónomas /loop y /goal: Usa /loop para la convergencia de invariantes locales (ciclos iterativos de prueba y corrección con persistencia de sesión) y /goal para la entrega autónoma a escala macro, durante varias horas y a través de todo el stack de agentes.

Qué aprenderás aquí

• Cómo organizar tu stack de agentes CLI en plano de control → razonamiento → ejecución → verificación → integración.
• Cómo Orca convierte las tareas de las especificaciones en DAGs de dependencias y administra sesiones de agentes, reintentos y worktrees de Git aislados.
• Una matriz de enrutamiento de tareas de 16 puntos que define workers principales, revisores, aislamiento de worktrees y reglas de escalamiento entre modelos.
• Flujos de ejecución multiagente por fases para Spec Kit y OpenSpec.
• Un pipeline de triaje brownfield de Jira que procesa bugs entrantes sin desperdiciar tokens de modelos de frontera.
• Un esquema JSON/YAML de contrato de tarea para agentes, listo para producción, para la ejecución de DAGs.
• Cómo diseñar skills /loop y /goal para flujos de ingeniería autónomos con circuit breakers.
• Medidas operativas para mitigar 13 modos de falla comunes en sistemas multiagente.
• Una hoja de ruta de implementación en 3 etapas, desde la prueba de concepto hasta una plataforma empresarial.

1. Análisis del stack: especialización sobre redundancia

Ejecutar cuatro asistentes de código de frontera sin límites claros desperdicia capacidad de cómputo. Cada herramienta y modelo de tu stack tiene propiedades distintas en cuanto a capacidad de contexto, velocidad, precio, integración con el IDE y sesgos cognitivos.

Por qué importa la diversidad de modelos

Cuando los modelos Claude revisan código generado por modelos Claude, comparten puntos ciegos cognitivos. Si el agente que escribe el código interpreta mal un requisito, el agente revisor suele hacer la misma suposición.

Combinar un worker de escritura de Anthropic (Cursor / Opus 5 Max) con un worker de revisión de OpenAI (Copilot / GPT-5.6 Sol) crea un control de verificación ortogonal. El revisor evalúa el diff del AST sin heredar el historial de prompts del autor.

2. Arquitectura de orquestación: planos de control, ejecución y almacenamiento

Una arquitectura multiagente empresarial desacopla qué se debe hacer (especificaciones) de quién decide (plano de control), quién programa la ejecución (runtime de orquestación) y dónde ocurren los cambios (sandboxes de los workers).

                               ┌────────────────────────┐
                               │       Jira Intake      │
                               │ (Bugs, Features, Tech) │
                               └───────────┬────────────┘
                                           │ Readiness Gate >= 80
                                           ▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ CONTROL PLANE: OpenCode (Claude Opus 5 High 1M)                                        │
│  - Evaluates Jira Triage Reports & Owns OpenSpec Delta Specs                           │
│  - Synthesizes System Architecture & Emits Machine-Readable Task DAGs                  │
└──────────────────────────────────────────┬─────────────────────────────────────────────┘
                                           │ Dispatches Task Contract DAG
                                           ▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ EXECUTION PLANE: Orca Runtime Orchestrator                                             │
│  - Manages Session State, Retries, Timeouts, and Resource Concurrency                  │
│  - Provisions Git Worktrees & Runs CLI Agents over MCP / Subprocess Protocol           │
├──────────────────────────────────────────┬─────────────────────────────────────────────┤
│                                          │                                             │
│   ┌───────────────────────────────────┐  │  ┌──────────────────────────────────────┐   │
│   │ TRIAGE POD (Read-Only)            │  │  │ IMPLEMENTATION POD (Isolated Worktree) │   │
│   │ • agy (Gemini Flash): Search/Git  │  │  │ • Cursor (Opus Max): Code & Refactor │   │
│   │ • Copilot (GPT-5.6): Critic       │  │  │ • agy (Gemini Flash): Unit Tests     │   │
│   │ • OpenCode: Root-Cause Synthesis  │  │  │ • Copilot (GPT-5.6): Adversarial Rev │   │
│   └───────────────────────────────────┘  │  └──────────────────────────────────────┘   │
└──────────────────────────────────────────┴─────────────────────────────────────────────┘
                                           │
                                           ▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ STORAGE & INTEGRATION PLANE                                                            │
│  • OpenSpec Registry (`openspec/specs/`) & Spec Kit Directory (`.specify/`, `specs/`)  │
│  • Isolated Git Worktrees (`.worktrees/<ticket-id>/`) & Signed Pull Requests           │
└────────────────────────────────────────────────────────────────────────────────────────┘

Límites y protocolos de los componentes

[!NOTE] Nota sobre la arquitectura de referencia: En este diseño, Orca representa el patrón de daemon para el runtime de ejecución. Los equipos pueden implementar esta capa con servidores personalizados de Model Context Protocol (MCP), workers en segundo plano de Python/Go u orquestadores de flujos de trabajo como Temporal.

1. El plano de control (OpenCode): Actúa como Staff Engineer. No escribe código repetitivo de rutina ni ejecuta búsquedas en 50 archivos. En cambio, lee expedientes de triaje, formula propuestas de OpenSpec, hace cumplir las reglas arquitectónicas y genera contratos de tareas normalizados.
2. El plano de ejecución (Orca): Actúa como programador de tareas. Recibe un DAG de tareas de OpenCode, programa lotes de ejecución paralela, aprovisiona worktrees de Git aislados, monitorea las señales de actividad de los procesos y gestiona los reintentos cuando falla la validación.
3. El protocolo de comunicación (MCP): Los agentes se comunican con Orca mediante servidores de herramientas MCP estándar (por ejemplo, orca_spawn_agent, orca_run_validation, orca_request_review).
4. El plano de almacenamiento (Git y OpenSpec): Los archivos delta de OpenSpec y los documentos de Spec Kit sirven como memoria compartida inmutable. Como se establece en Parte 1: Espacios de trabajo agénticos, la raíz del espacio de trabajo contiene la capa de conocimiento compartida y el registro de especificaciones. El código de la aplicación vive en checkouts de submódulos o worktrees aislados.

3. Matriz completa de enrutamiento de tareas

La siguiente tabla define reglas estrictas de enrutamiento para toda la plataforma. Cada tarea se clasifica según el worker principal, el revisor, el modelo de concurrencia, el aislamiento de worktree, el nivel de riesgo y los factores que activan el escalamiento entre modelos.

4. Flujo de trabajo de Spec Kit: ejecución multiagente por fases

GitHub Spec Kit estructura la entrega de ingeniería en fases progresivas. Distribuimos la responsabilidad entre modelos según la exigencia cognitiva:

Convertir tasks.md en un DAG de ejecución de Orca

tasks.md no debería quedar como una lista de verificación pasiva para humanos. OpenCode da formato a tasks.md con bloques legibles por máquina que Orca procesa para construir su grafo de dependencias:

<!-- orca-task-manifest
tasks:
  - id: TASK-01
    title: "Generate additive DDL migration for audit_events table"
    agent: agy
    model: gemini-3.7-flash-high
    write_access: true
    worktree: "wt-feature-audit-ddl"
    validation_command: "npm run db:migrate:dry-run"
    depends_on: []
    notes: "Additive greenfield DDL only; stateful migrations escalate to Tier 4."

  - id: TASK-02
    title: "Implement AuditRepository with bulk batching"
    agent: cursor
    model: claude-opus-5-max
    write_access: true
    worktree: "wt-feature-audit-impl"
    validation_command: "npm run test:unit -- src/infra/AuditRepository.test.ts"
    depends_on: [TASK-01]

  - id: TASK-03
    title: "Generate unit tests for AuditRepository"
    agent: agy
    model: gemini-3.7-flash-high
    write_access: true
    worktree: "wt-feature-audit-tests"
    validation_command: "npm run test:unit"
    depends_on: [TASK-01]

  - id: TASK-04
    title: "Adversarial security review of AuditRepository"
    agent: copilot
    model: gpt-5.6-sol-medium
    write_access: false
    worktree: "wt-feature-audit-review"
    validation_command: "orca verify-security-gate"
    depends_on: [TASK-02, TASK-03]
-->

Orca ejecuta TASK-02 (implementación en wt-feature-audit-impl) y TASK-03 (generación de pruebas en wt-feature-audit-tests) de forma concurrente una vez que TASK-01 termina. Al asignar sub-worktrees específicos para cada tarea, Orca elimina la contención por .git/index.lock entre workers paralelos.

5. Flujo de trabajo de OpenSpec: gobernanza centrada en cambios

OpenSpec representa el estado del sistema como capacidades vivas en openspec/specs/ y los cambios en curso como deltas en openspec/changes/.

Current Canonical Specs
        │
        ▼
   1. Explore ────────► 2. Propose (Delta) ────────► 3. Design & Tasks
 (agy / Gemini Flash)   (OpenCode / Opus High)       (OpenCode / Opus High)
                                                            │
                                                            ▼
   6. Archive ◄──────── 5. Verify (Gate) ◄────────── 4. Apply (Execution)
(OpenCode ONLY)      (Copilot + OpenCode)            (Cursor / Opus Max)

Regla de aislamiento: un cambio de OpenSpec = un pod de Orca

Para evitar que agentes concurrentes corrompan las especificaciones del repositorio:

1. Responsable del cambio: OpenCode se designa como el único responsable del cambio. Solo OpenCode tiene permisos de escritura para las propuestas, especificaciones y diseños de openspec/changes/<change-id>/.
2. Bloqueos de pod: Orca asigna un ID de cambio único y mantiene un bloqueo exclusivo sobre ese directorio durante la planificación.
3. Delegación de ejecución: Cursor y agy reciben acceso de lectura a las especificaciones delta y acceso de escritura únicamente a las rutas de código fuente definidas en tasks.md.
4. Autoridad de archivo de un solo escritor: Solo OpenCode está autorizado para ejecutar openspec archive. El archivado convierte las especificaciones delta en la fuente de verdad canónica (openspec/specs/). Permitir que los workers de implementación archiven especificaciones provoca divergencias en la documentación.

6. Motor de triaje brownfield de Jira

En bases de código brownfield, pasar directamente de un ticket de Jira a editar código consume tokens en suposiciones equivocadas. Un pipeline de triaje automatizado recopila evidencia antes de tocar el código.

Incoming Jira Issue ──► 1. Parallel Investigation Pod (4x agy / Gemini Flash)
                                │ (Search Code, Git History, Specs, Run Tests)
                                ▼
                        2. Root-Cause Hypothesis (OpenCode / Opus High)
                                │
                                ▼
                        3. Adversarial Challenge (Copilot / GPT-5.6 Sol)
                                │
                                ▼
                        4. Readiness Gate (Score >= 80)
                                │
                 ┌──────────────┴──────────────┐
                 ▼                             ▼
       Score >= 80 (READY)            Score < 80 (BLOCKED)
       Spawn Implementation Pod       Post Dossier to Jira / Request Info

El modelo de puntuación de preparación del issue

Para superar el control, el expediente de triaje debe obtener una puntuación de $\ge 80/100$ en cinco dimensiones:

$\text{Readiness Score} = S_{\text{repro}} + S_{\text{loc}} + S_{\text{spec}} + S_{\text{blast}} + S_{\text{critic}}$

1. Determinismo de la reproducción ($S_{\text{repro}}$, 0–25 pts): Existe una prueba fallida o un comando curl. Para bugs intermitentes, también califican las trazas de telemetría capturadas o los scripts de reproducción de carga.
2. Localización del código ($S_{\text{loc}}$, 0–25 pts): Los archivos, funciones y números de línea relevantes se identifican con precisión mediante trazas de pila.
3. Alineación con las especificaciones ($S_{\text{spec}}$, 0–20 pts): Las capacidades relevantes de OpenSpec o los documentos de Spec Kit confirman el comportamiento esperado.
4. Análisis del alcance del impacto ($S_{\text{blast}}$, 0–15 pts): Se identifican los módulos dependientes y los riesgos de cambios incompatibles.
5. Aprobación del crítico adversarial ($S_{\text{critic}}$, 0–15 pts): Copilot / GPT-5.6 Sol confirmó que no quedan contrahipótesis sin atender.

Ejecutar el triaje con Gemini 3.7 Flash y GPT-5.6 Sol permite a los equipos procesar 50+ tickets diarios por una fracción del costo de sesiones sin guía con modelos de frontera.

7. Topologías de pods: pods de triaje frente a pods de implementación

Orca aísla el trabajo de los agentes en dos perfiles de ejecución. La exploración, centrada en la lectura, nunca pone en riesgo la seguridad del repositorio, mientras que la implementación, centrada en la escritura, se ejecuta en sandboxes aislados.

8. El contrato de tarea para agentes normalizado

Las tareas deben serializarse en un esquema estricto y validado antes de programarse en Orca.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "OrcaAgentTaskContract",
  "type": "object",
  "required": [
    "taskId",
    "changeId",
    "title",
    "agent",
    "model",
    "risk",
    "complexity",
    "dependsOn",
    "parallel",
    "writeAccess",
    "worktree",
    "reviewer",
    "acceptanceCriteria",
    "validationCommand",
    "retryPolicy"
  ],
  "properties": {
    "taskId": { "type": "string", "example": "TASK-042" },
    "changeId": { "type": "string", "example": "change-2026-08-auth-refresh" },
    "title": { "type": "string" },
    "agent": { "type": "string", "enum": ["opencode", "cursor", "agy", "copilot"] },
    "model": { "type": "string", "enum": ["claude-opus-5-high", "claude-opus-5-max", "gemini-3.7-flash-high", "gpt-5.6-sol-medium"] },
    "risk": { "type": "string", "enum": ["low", "medium", "high", "critical"] },
    "complexity": { "type": "string", "enum": ["trivial", "moderate", "complex", "architectural"] },
    "dependsOn": { "type": "array", "items": { "type": "string" } },
    "parallel": { "type": "boolean" },
    "writeAccess": {
      "type": "object",
      "properties": {
        "enabled": { "type": "boolean" },
        "allowedPaths": { "type": "array", "items": { "type": "string" } },
        "deniedPaths": { "type": "array", "items": { "type": "string" } }
      },
      "required": ["enabled", "allowedPaths"]
    },
    "worktree": {
      "type": "object",
      "properties": {
        "required": { "type": "boolean" },
        "path": { "type": "string" },
        "baseBranch": { "type": "string" }
      },
      "required": ["required"]
    },
    "reviewer": {
      "type": "object",
      "properties": {
        "agent": { "type": "string", "enum": ["copilot", "opencode", "human"] },
        "model": { "type": "string" },
        "required": { "type": "boolean" }
      },
      "required": ["agent", "required"]
    },
    "acceptanceCriteria": { "type": "array", "items": { "type": "string" } },
    "validationCommand": { "type": "string" },
    "retryPolicy": {
      "type": "object",
      "properties": {
        "maxRetries": { "type": "integer", "default": 2 },
        "escalateOnFailure": { "type": "boolean" },
        "escalationAgent": { "type": "string" },
        "escalationModel": { "type": "string" }
      },
      "required": ["maxRetries", "escalateOnFailure"]
    }
  }
}

9. El ciclo resiliente de reintentos y revisión

Cuando una implementación no supera la revisión, no borres la sesión del worker. Empezar desde cero hace que se pierda memoria de trabajo valiosa sobre particularidades del compilador y estructuras de módulos.

Orca mantiene la persistencia de las sesiones de los workers mediante dos mecanismos:

1. Pipes interactivos de entrada y salida estándar: Envían los hallazgos de la revisión directamente a la entrada estándar activa del worker.
2. Flags de restauración de sesión: Usan flags de CLI (--session-id <id> o --resume) para restaurar puntos de control del contexto.

Worker Writes Code in Worktree ──► Automated Test Gate (Orca)
                                           │
                           ┌───────────────┴───────────────┐
                           ▼                               ▼
                 PASS: Reviewer Gate               FAIL: Retry Loop
               (Copilot / GPT-5.6 Sol)           (Worker gets test log)
                           │                               │
                 ┌─────────┴─────────┐                     │
                 ▼                   ▼                     │
               PASS                FAIL                    │
          Merge into PR    Structured feedback injected ───┘

10. Optimización de costos y latencia: la escala de escalamiento económico

Los costos de inferencia sin control agotarán los presupuestos del equipo. La plataforma aplica una escala de escalamiento económico:

Cost & Latency
      ▲
      │                                                [Tier 4: Opus 5 Max]
      │                                                Deep AST Refactor / Complex Debug
      │
      │                                [Tier 3: Opus 5 High (1M)]
      │                                System Architecture / OpenSpec Governance
      │
      │                [Tier 2: GPT-5.6 Sol Medium]
      │                Adversarial Review / Security Audit / Triage Challenge
      │
      │    [Tier 1: Gemini 3.7 Flash High]
      │    Code Search / Git Archaeology / Test Gen / Log Parsing
      └──────────────────────────────────────────────────────────────────────────►
                                                                  Task Complexity

• La amplitud es económica: El 80% de todos los tokens pasa por el nivel 1 (Gemini 3.7 Flash mediante agy).
• La profundidad es selectiva: El nivel 4 (Opus 5 Max) se ejecuta solo para refactorizaciones complejas de AST y algoritmos difíciles.
• Reglas de escalamiento: Si un worker del nivel 1 no logra completar una tarea después de 2 reintentos, Orca escala automáticamente la tarea al nivel 4.

11. Modos de falla y salvaguardas de producción

Desplegar agentes autónomos en bases de código brownfield de gran tamaño introduce riesgos operativos específicos.

12. Orquestación autónoma de objetivos: presentación de las skills /loop y /goal

Para pasar de la asistencia prompt por prompt a una ingeniería autodirigida, la plataforma introduce dos primitivas de ejecución: /loop y /goal.

/goal (Macro Multi-Hour Orchestrator: OpenCode / Opus 5 High)
  ├── 1. Decomposes master goal into DAG milestones in `.goal/state.json`
  ├── 2. Spawns read-only Triage Pods (agy) to gather reproduction evidence
  ├── 3. Emits OpenSpec Delta Specs & Task Contracts
  └── 4. Schedules Orca Implementation Pods
        │
        ▼
    /loop (Micro-Iterator: Cursor Agent + agy + Copilot Reviewer)
      ├── State Capture: agy runs tests and captures error stacks
      ├── Targeted Patch: Cursor modifies code in isolated worktree
      ├── Test Gate: Orca runs build and unit test suites
      └── Review Gate: Copilot verifies diff invariants

La skill /loop: convergencia de invariantes locales

La skill /loop converge hacia una condición local de aprobación determinista (por ejemplo, que todas las pruebas unitarias pasen o que no haya errores de TypeScript).

---
name: loop
description: Iterates on a localized code invariant using Cursor implementation, agy test runs, and Copilot review until convergence or iteration ceiling.
---

# /loop Skill Specification

## Invocation Parameters
- `invariant`: Pass condition (e.g., `npm run test:auth`, `tsc --noEmit`).
- `worker`: Default `cursor` (Claude Opus 5 Max).
- `runner`: Default `agy` (Gemini 3.7 Flash High).
- `reviewer`: Default `copilot` (GPT-5.6 Sol Medium).
- `max_iterations`: Default `5`.

## Execution Cycle
1. **Capture State:** Runner (`agy`) executes `validationCommand` and saves error stacks to `.loop/scratchpad.json`.
2. **Targeted Patch:** Worker (`Cursor`) edits source files in the active session.
3. **Automated Gate:** Runner re-runs `validationCommand`. If failing, logs pipe back to worker.
4. **Adversarial Audit:** Reviewer (`Copilot`) checks for specification regressions or weakened test assertions.
5. **Termination:** Returns `CONVERGED` when all gates pass, or `BLOCKED` after 5 iterations.

La skill /goal: entrega autónoma a escala macro durante la noche

Mientras que /loop opera sobre archivos individuales, /goal opera sobre backlogs completos de funcionalidades y colas de issues.

1. Estado en disco (.goal/): El orquestador escribe transacciones en .goal/state.json y planes para humanos en .goal/GOAL.md. Si una máquina se reinicia, /goal retoma el trabajo desde el último punto de control confirmado.
2. Circuit breakers y límites financieros: Cada objetivo impone un límite estricto de gasto (por ejemplo, max_cost_usd: 20.00) y se detiene si fallan 3 tareas consecutivas.
3. Tokens de finalización para ejecución sin interfaz: Señala la finalización de trabajos en segundo plano mediante <!-- GOAL_COMPLETE --> o <!-- GOAL_CANCELLED -->.

13. Diseño arquitectónico general y hoja de ruta por fases

7 principios arquitectónicos inmutables

1. Separación de responsabilidades: Separa la planificación (OpenCode) de la escritura de código (Cursor), la exploración (agy) y la revisión (Copilot).
2. Evidencia antes de inferencias: Nunca escribas código sin casos de prueba reproducibles o trazas de símbolos del AST.
3. Fundamentación en especificaciones: Registra todas las transiciones de estado en deltas de OpenSpec o artefactos de Spec Kit.
4. Revisión entre modelos: Combina distintas familias de modelos entre la escritura y la revisión.
5. Continuidad de sesión durante los reintentos: Mantén activas las sesiones de los workers durante las revisiones en lugar de borrar su memoria.
6. Enrutamiento económico: Dirige las tareas de búsqueda y prueba de alto volumen a modelos Flash económicos.
7. Gobernanza de un solo escritor: Solo OpenCode puede archivar especificaciones para convertirlas en la fuente de verdad canónica.

Hoja de ruta de implementación por fases

STAGE 1: Foundations & Manual Routing (Weeks 1 - 4)
• Define subagent prompt templates in `.cursor/subagents/` and `.claude/agents/`.
• Adopt OpenSpec conventions for all new feature proposals.
• Establish manual CLI routing: agy for search, Cursor for code, Copilot for review.

STAGE 2: Orca Runtime, Triage Automation & /loop (Weeks 5 - 10)
• Deploy Orca runtime daemon to ingest JSON/YAML Task Contracts.
• Automate Jira webhook integration for parallel Triage Pod execution.
• Implement automated Jira Readiness Gate scoring (>= 80 threshold).
• Introduce the `/loop` skill for iterative local test/fix cycles with session persistence.

STAGE 3: Fully Autonomous /goal Platform (Weeks 11 - 16)
• Deploy `/goal` macro orchestrator for overnight batch issue execution.
• Enable dynamic economic load balancing and automatic tier escalation.
• Automate OpenSpec archiving, regression verification, and signed PR creation.
• Build telemetry dashboards tracking cost per ticket, pass rates, and cycle times.

Conclusión

Construir una plataforma de desarrollo de código multiagente lista para producción no consiste en elegir un único ganador entre los modelos de frontera. Es un ejercicio de ingeniería de sistemas distribuidos: establecer contratos de datos estrictos, aislar los efectos secundarios en worktrees dentro de sandboxes y combinar modelos complementarios para detectar los puntos ciegos de cada uno.

Al ubicar a OpenCode como arquitecto de sistemas, a Orca como runtime determinista, a agy como explorador de alto rendimiento, a Cursor como motor de código de precisión y a GitHub Copilot como crítico independiente, los equipos de ingeniería pueden maximizar la velocidad de entrega y mantener bajo control los costos de inferencia.

Fuentes

Fuentes principales y sistemas consultados el August 21, 2026:

• Documentos técnicos de arquitectura y capacidades de ventana de contexto de Anthropic Claude Opus 5 — anthropic.com/research
• Benchmarks de rendimiento y capacidad de procesamiento de Google DeepMind Gemini 3.7 Flash High — deepmind.google/technologies/gemini
• Referencia de modelos de la serie OpenAI GPT-5.6 Sol — openai.com/research
• Framework de especificaciones centrado en cambios de OpenSpec — openspec.dev
• Kit de herramientas de desarrollo guiado por especificaciones de GitHub Spec Kit — github.com/github/spec-kit
• Especificación abierta de Model Context Protocol (MCP) — modelcontextprotocol.io
• Referencia operativa de Git Worktree — git-scm.com/docs/git-worktree

Síntesis editorial e invariantes del sistema: El esquema de contrato de tareas de Orca, las topologías de pods (triaje frente a implementación), la formulación de la puntuación de preparación de Jira ($S_{\text{repro}} + S_{\text{loc}} + \dots$) y la escala de escalamiento económico multiagente representan una síntesis arquitectónica original diseñada para entornos de ingeniería empresarial.

Artículos relacionados en este devlog:

• Espacios de trabajo agénticos: submódulos, skills, conocimiento y entrega guiada por especificaciones
• Agente de ingeniería sénior: orquestación de subagentes e ingeniería de bucles
• Orquestación de IA: prompts de sistema, skills, MCP y plugins
• Subagentes de Cursor y Claude Code: flujos de trabajo multiagente prácticos