Orchestrating a Multi-Agent CLI Stack: OpenCode, Cursor, agy, Copilot, Orca, and OpenSpec

Most engineering teams exploring multi-agent coding make a costly mistake. They treat distinct coding agents as interchangeable assistants. When an engineer opens a ticket, they throw one model at the entire problem. That model searches legacy code, writes specs, refactors ASTs, runs tests, and drafts pull requests.

This unsegmented approach leads to predictable failures. Teams suffer from runaway token bills and polluted context windows. Models enter hallucination loops where they approve their own flawed logic. Meanwhile, concurrent workers trigger Git merge conflicts.

On August 21, 2026, we explore an architectural hypothesis and speculative blueprint for coordinating an opinionated CLI coding-agent stack: OpenCode (Claude Opus 5 High, 1M context), Cursor Agent (Claude Opus 5 Max), agy (Gemini 3.7 Flash High), and GitHub Copilot (GPT-5.6 Sol Medium). We analyze how to orchestrate these tools using Orca (our reference DAG execution runtime) alongside OpenSpec and GitHub Spec Kit specifications and Jira brownfield triage.

[!NOTE] Architectural Hypothesis & Disclaimer: This guide presents an exploratory hypothesis and speculative systems analysis based on an opinionated selection of CLI agents, frontier models, and orchestration patterns. It reflects design research into how emerging developer tools can be structured into resilient, multi-agent engineering pipelines rather than an official vendor standard.

Audience: Written for Engineers and Architects building autonomous coding agent pipelines, platform teams, and technical leads moving from single prompts to multi-agent systems.

TL;DR

• Break Up the Monolith: Never let one agent own a task from start to finish. Separate the workflow into Control Plane (OpenCode / Opus 5 High), Execution Plane (Orca runtime), Exploration Workers (agy / Gemini 3.7 Flash), Heavy Refactoring (Cursor / Opus 5 Max), and Independent Review (Copilot / GPT-5.6 Sol).
• The Economic Escalation Ladder: Reading, searching, archaeology, and test runs make up 70% of brownfield engineering. Route these high-volume steps to ultra-fast, cheap models (Gemini 3.7 Flash via agy). Save frontier reasoning (Opus 5 High/Max) for system design, delta specs, and complex code refactoring.
• Two Pod Topologies: Separate read-only Triage Pods (for issue investigation, Git history, and root-cause analysis) from write-isolated Implementation Pods (running inside dedicated Git worktrees with automated test gates).
• Artifacts as Contracts: Natural language prompts are too loose for agent handoffs. Use OpenSpec delta specs, Spec Kit artifacts, and a normalized machine-readable Agent Task Contract (JSON/YAML) to define inputs, file write scopes, test commands, and retry budgets.
• Cross-Model Review: Never let an implementation model grade its own work. An Opus-generated refactor must be reviewed by an independent GPT-5.6 Sol model to catch blind spots.
• Jira Readiness Gate: Never allow a Jira issue to trigger direct code edits. Run an automated evidence-gathering phase that calculates an Issue Readiness Score before starting an implementation pod.
• Autonomous /loop & /goal Primitives: Use /loop for local invariant convergence (iterative test-fix cycles with session persistence) and /goal for macro, multi-hour autonomous delivery across the full agent stack.

What You Will Learn Here

• How to map your CLI agent stack across Control Plane → Reasoning → Execution → Verification → Integration.
• How Orca translates spec tasks into dependency DAGs and manages agent sessions, retries, and isolated Git worktrees.
• A 16-point Task Routing Matrix defining primary workers, reviewers, worktree isolation, and model escalation rules.
• Phased multi-agent execution flows for Spec Kit and OpenSpec.
• A Jira Brownfield Triage Pipeline that processes incoming bugs without wasting frontier tokens.
• A production-ready Agent Task Contract JSON/YAML schema for DAG execution.
• How to design /loop and /goal skills for autonomous engineering workflows with circuit breakers.
• Operational mitigations for 13 common multi-agent failure modes.
• A 3-stage implementation roadmap from Proof-of-Concept to enterprise platform.

1. Stack Analysis: Specialization over Redundancy

Running four frontier coding assistants without clear boundaries wastes compute. Each tool and model in your stack has distinct properties in context capacity, speed, pricing, IDE hooks, and cognitive biases.

Why Model Diversity Matters

When Claude models review code generated by Claude models, they share cognitive blind spots. If the authoring agent misinterprets a requirement, the reviewing agent often makes the same assumption.

Pairing an Anthropic write worker (Cursor / Opus 5 Max) with an OpenAI review worker (Copilot / GPT-5.6 Sol) creates an orthogonal verification gate. The reviewer evaluates the AST diff without inheriting the author’s prompt history.

2. Orchestration Architecture: Control, Execution, and Storage Planes

An enterprise multi-agent architecture decouples what needs to be done (specs) from who decides (control plane), who schedules (orchestration runtime), and where changes happen (worker sandboxes).

                               ┌────────────────────────┐
                               │       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           │
└────────────────────────────────────────────────────────────────────────────────────────┘

Component Boundaries & Protocols

[!NOTE] Reference Architecture Note: In this blueprint, Orca represents the execution runtime daemon pattern. Teams can implement this layer using custom Model Context Protocol (MCP) servers, Python/Go background workers, or workflow orchestrators like Temporal.

1. The Control Plane (OpenCode): Acts as the Staff Engineer. It does not write routine boilerplate or run searches across 50 files. Instead, it reads triage dossiers, formulates OpenSpec proposals, enforces architectural rules, and generates normalized task contracts.
2. The Execution Plane (Orca): Acts as the Scheduler. It takes a task DAG from OpenCode, schedules parallel execution batches, provisions isolated Git worktrees, tracks process heartbeats, and handles retries upon validation failure.
3. The Communication Protocol (MCP): Agents communicate with Orca using standard MCP tool servers (e.g., orca_spawn_agent, orca_run_validation, orca_request_review).
4. The Storage Plane (Git & OpenSpec): OpenSpec delta files and Spec Kit docs serve as immutable shared memory. As established in Part 1: Agentic Workspaces, the workspace root holds the shared knowledge layer and spec registry. Application code lives in submodule checkouts or isolated worktrees.

3. Comprehensive Task-Routing Matrix

The table below defines strict routing rules across the platform. Every task is categorized by primary worker, reviewer, concurrency model, worktree isolation, risk level, and model escalation triggers.

4. Spec Kit Workflow: Phased Multi-Agent Execution

GitHub Spec Kit structures engineering delivery through progressive phases. We divide ownership across models based on cognitive demand:

Turning tasks.md into an Orca Execution DAG

tasks.md should not remain a passive human checklist. OpenCode formats tasks.md with machine-readable blocks that Orca ingests to build its dependency graph:

<!-- 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 executes TASK-02 (implementation in wt-feature-audit-impl) and TASK-03 (test generation in wt-feature-audit-tests) concurrently once TASK-01 completes. By allocating task-scoped sub-worktrees, Orca eliminates .git/index.lock contention across parallel workers.

5. OpenSpec Workflow: Change-Centric Governance

OpenSpec represents system state as living capabilities in openspec/specs/ and in-flight changes as deltas in 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)

Rule of Isolation: One OpenSpec Change = One Orca Pod

To prevent concurrent agents from corrupting repository specifications:

1. The Change Owner: OpenCode is designated as the sole Change Owner. Only OpenCode has write permissions for openspec/changes/<change-id>/ proposals, specs, and designs.
2. Pod Locks: Orca allocates a unique change ID and maintains an exclusive lock on that directory during planning.
3. Execution Delegation: Cursor and agy receive read access to delta specs and write access only to the source paths defined in tasks.md.
4. Single-Writer Archive Authority: Only OpenCode is authorized to run openspec archive. Archiving promotes delta specs into canonical truth (openspec/specs/). Letting implementation workers archive specs leads to documentation drift.

6. Jira Brownfield Triage Engine

In brownfield codebases, jumping directly from a Jira ticket into code editing burns tokens on wrong assumptions. An automated triage pipeline gathers evidence before code is touched.

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

The Issue Readiness Scoring Model

To pass the gate, the triage dossier must score $\ge 80/100$ across five dimensions:

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

1. Reproduction Determinism ($S_{\text{repro}}$, 0–25 pts): A failing test or curl command exists. For intermittent bugs, captured telemetry traces or load replay scripts qualify.
2. Code Localization ($S_{\text{loc}}$, 0–25 pts): Target files, functions, and line numbers are pinpointed with stack traces.
3. Specification Alignment ($S_{\text{spec}}$, 0–20 pts): Relevant OpenSpec capabilities or Spec Kit docs confirm expected behavior.
4. Blast Radius Analysis ($S_{\text{blast}}$, 0–15 pts): Downstream dependent modules and breaking change risks are mapped.
5. Adversarial Critic Clearance ($S_{\text{critic}}$, 0–15 pts): Copilot / GPT-5.6 Sol confirmed no unhandled counter-hypotheses.

Running triage on Gemini 3.7 Flash and GPT-5.6 Sol allows teams to process 50+ tickets daily at a fraction of the cost of unguided frontier sessions.

7. Pod Topologies: Triage Pods vs. Implementation Pods

Orca isolates agent work into two execution profiles. Read-heavy discovery never threatens repo safety, while write-heavy implementation runs in isolated sandboxes.

8. The Normalized Agent Task Contract

Tasks must be serialized into a strict, validated schema before scheduling in 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. The Resilient Retry and Review Loop

When an implementation fails review, do not wipe the worker session. Starting from scratch loses valuable working memory about compiler quirks and module structures.

Orca maintains worker session persistence through two mechanisms:

1. Interactive Stdio Pipes: Streaming review findings directly into the worker’s active standard input.
2. Session Restoration Flags: Using CLI flags (--session-id <id> or --resume) to restore context checkpoints.

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. Cost and Latency Optimization: The Economic Escalation Ladder

Uncontrolled inference costs will drain team budgets. The platform enforces an Economic Escalation Ladder:

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

• Breadth is Cheap: 80% of all tokens flow through Tier 1 (Gemini 3.7 Flash via agy).
• Depth is Selective: Tier 4 (Opus 5 Max) runs only for complex AST refactors and tricky algorithms.
• Escalation Rules: If a Tier 1 worker fails a task after 2 retries, Orca automatically escalates the task to Tier 4.

11. Failure Modes and Production Safeguards

Deploying autonomous agents on large brownfield codebases introduces distinct operational risks.

12. Autonomous Goal Orchestration: Introducing /loop and /goal Skills

To transition from prompt-by-prompt assistance to self-directed engineering, the platform introduces two execution primitives: /loop and /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

The /loop Skill: Local Invariant Convergence

The /loop skill converges on a deterministic local pass condition (e.g., all unit tests passing, zero TypeScript errors).

---
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.

The /goal Skill: Macro Overnight Autonomous Delivery

While /loop operates on individual files, /goal operates across entire feature backlogs and issue queues.

1. State on Disk (.goal/): The orchestrator writes transactions to .goal/state.json and human plans to .goal/GOAL.md. If a machine reboots, /goal resumes from the last confirmed checkpoint.
2. Circuit Breakers & Financial Caps: Each goal enforces a hard spending cap (e.g., max_cost_usd: 20.00) and stops if 3 consecutive tasks fail.
3. Headless Completion Tokens: Signals completion in background jobs using <!-- GOAL_COMPLETE --> or <!-- GOAL_CANCELLED -->.

13. Master Architecture Blueprint & Phased Roadmap

7 Immutable Architectural Principles

1. Separation of Concerns: Separate planning (OpenCode) from coding (Cursor), exploration (agy), and review (Copilot).
2. Evidence Before Inferences: Never write code without reproducible test cases or AST symbol traces.
3. Spec-Driven Grounding: Commit all state transitions to OpenSpec deltas or Spec Kit artifacts.
4. Cross-Model Review: Pair distinct model families across the write-review boundary.
5. Session Continuity on Retries: Keep worker sessions alive during revisions instead of wiping memory.
6. Economic Routing: Direct high-volume search and test tasks to cheap Flash models.
7. Single-Writer Governance: Only OpenCode can archive specifications into canonical truth.

Phased Implementation Roadmap

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.

Conclusion

Building a production-ready multi-agent coding platform is not about picking a single winner among frontier models. It is an exercise in distributed systems engineering: establishing strict data contracts, isolating side effects in sandboxed worktrees, and pairing complementary models to catch each other’s blind spots.

By positioning OpenCode as the systems architect, Orca as the deterministic runtime, agy as the high-throughput explorer, Cursor as the precision code engine, and GitHub Copilot as the independent critic, engineering teams can maximize delivery velocity while keeping inference costs under control.

Sources

Primary sources and systems consulted on August 21, 2026:

• Anthropic Claude Opus 5 Architectural Whitepapers & Context Window Capabilities — anthropic.com/research
• Google DeepMind Gemini 3.7 Flash High Performance & Throughput Benchmarks — deepmind.google/technologies/gemini
• OpenAI GPT-5.6 Sol Series Model Reference — openai.com/research
• OpenSpec Change-Centric Specification Framework — openspec.dev
• GitHub Spec Kit Specification-Driven Development Toolkit — github.com/github/spec-kit
• Model Context Protocol (MCP) Open Specification — modelcontextprotocol.io
• Git Worktree Operational Reference — git-scm.com/docs/git-worktree

Editorial Synthesis & System Invariants: The Orca task contract schema, pod topologies (Triage vs. Implementation), Jira Readiness Scoring formulation ($S_{\text{repro}} + S_{\text{loc}} + \dots$), and the multi-agent economic escalation ladder represent original architectural synthesis designed for enterprise engineering environments.

Related articles in this devlog:

• Agentic Workspaces: Submodules, Skills, Knowledge, and Spec-Driven Delivery
• Senior Engineer Agent: Orchestrating Subagents and Loop Engineering
• AI Orchestration: System Prompts, Skills, MCP, and Plugins
• Cursor Subagents and Claude Code: Practical Multi-Agent Workflows