OpenCode Orchestrator — Summary

OpenCode Orchestrator is a production-grade multi-agent orchestration engine published as the npm package opencode-orchestrator (v1.2.69), designed specifically for the OpenCode CLI environment. It implements a hub-and-spoke architecture with four agent types (Commander, Planner, Worker, Reviewer) coordinated via work-stealing queues and MVCC session synchronization. The engine's philosophy is "Explore → Learn → Adapt → Act" — each agent phase is evidence-based, demanding direct file reads and command execution over memory or pattern-matching. Technically notable for its low-level concurrency primitives: MVCC state synchronization, Chase-Lev work-stealing deques, object/string/buffer memory pools, and a Rust-based connection pool, making it the most performance-engineering-focused framework in the batch. The modular prompt system composes agent system prompts from named constants (CORE_PHILOSOPHY, COMMANDER_ROLE, etc.) allowing fine-grained behavior control. Compared to seeds: closest to claude-flow in hierarchical multi-agent coordination with a primary "commander" role, but OpenCode Orchestrator is single-tool (OpenCode only), ships no MCP server of its own, and focuses on process-level performance engineering rather than swarm topologies or consensus protocols.

OpenCode Orchestrator — Overview

Origin

Created by agnusdei1207. GitHub: https://github.com/agnusdei1207/opencode-orchestrator. npm package: opencode-orchestrator. Version 1.2.69 at analysis time. Also ships a Rust binary and a Docker image for isolated execution.

Philosophy

From the AGENTS.md (in Korean — the repo's primary language):

"Actions must be evidence-based. Permitted evidence: directly reading files, executing commands and observing output, running tests and observing results. Not valid: memory, assumptions, pattern matching alone."

The four-phase core philosophy:

• [EXPLORE]: Scan unknown territory — detect environment, never assume
• [LEARN]: Document discoveries — record patterns for future use
• [ADAPT]: Adjust to findings — match project's style and context
• [ACT]: Execute with confidence — build, test, verify, conclude

Key design choices

1. Work-stealing queues (Chase-Lev algorithm) — idle agents steal tasks from busy agents' queues, achieving natural load balancing without a central scheduler
2. MVCC state synchronization — multiple agents read/write shared state atomically, modeled after database MVCC (multi-version concurrency control)
3. Memory pools — object pool (200 slots), string intern pool, buffer pool (4KB chunks) to eliminate GC pressure during high-throughput agent runs
4. Rust connection pool — 4 processes, 30s idle timeout, managed by Rust for connection management
5. MSVP Monitor — Minimum Stable Value Polling — adaptive polling (500ms–5s) with stability detection before declaring a task complete

AGENTS.md mandates (absolute prohibitions)

• Never claim verification without reading the file
• Never modify code based on assumptions
• Never reference unverified functions, files, variables, types
• Never skip impact analysis or post-work verification
• Never mix refactoring and feature work in same change
• Never ignore potential conflicts with parallel agents working on same file

OpenCode Orchestrator — Architecture

Distribution

• npm package: opencode-orchestrator
• Install: npm install -g opencode-orchestrator
• Also available: Docker image via compose.yml; Rust binary in bin/
• Required runtime: Node.js (TypeScript), Rust (connection pool), Docker (optional isolation)

Directory structure

src/
  agents/
    commander.ts      # Master orchestrator (main agent)
    subagents/
      planner.ts      # Architecture/roadmap/TODO.md generator
      worker.ts       # File coding, TDD, documentation implementation
      reviewer.ts     # Verification, stability checking
    prompts/
      01_philosophy/  # CORE_PHILOSOPHY, ANTI_HALLUCINATION, ENVIRONMENT_DISCOVERY
      02_discovery/   # SEARCH_TOOLS
      03_planning/    # COMMANDER_LOOP_CONTINUATION, PLANNER prompts
      04_execution/   # WORKER prompts
      05_verification/# REVIEWER prompts
      06_mission/     # MISSION_STATUS_FORMAT
      07_agents/      # COMMANDER_FORBIDDEN, COMMANDER_REQUIRED
      08_tools/       # SHARED_LSP_TOOLS, SHARED_AST_TOOLS
  core/               # Session pool, work-stealing queue, MVCC
  hooks/              # Lifecycle hooks
  shared/             # Constants, interfaces
  tools/              # Tool definitions
  utils/              # Helpers

crates/               # Rust connection pool and binary
scripts/              # Build scripts
user-prompt/          # Shared workspace prompt injection

Shared workspace pattern

Agents share a .opencode/ directory for inter-agent communication. The Commander reads this directory to detect loop state and coordinate with sub-agents on sync issues.

Config

• opencode.jsonc — OpenCode configuration (hooks, plugin entry, CI detection)
• AGENTS.md — agent operating rules (Korean, with English prohibition lists)

Target AI tools

OpenCode CLI exclusively. This is a single-tool framework.

OpenCode Orchestrator — Components

Agent types (4)

Prompt modules (8 directories, ~20+ named constants)

Key prompt fragments used in agent composition:

• CORE_PHILOSOPHY — Explore/Learn/Adapt/Act table
• COMMANDER_ROLE / COMMANDER_IDENTITY
• COMMANDER_FORBIDDEN / COMMANDER_REQUIRED
• ANTI_HALLUCINATION_CORE — evidence-based mandate
• ENVIRONMENT_DISCOVERY — how to detect project environment
• COMMANDER_EXECUTION / COMMANDER_PARALLEL — parallel delegation rules
• COMMANDER_LOOP_CONTINUATION — how to resume from .opencode/ state
• COMMANDER_SYNC_HANDLING / COMMANDER_RECOVERY
• SHARED_LSP_TOOLS / SHARED_AST_TOOLS — language server and AST tool instructions
• MISSION_STATUS_FORMAT — output reporting format

Hooks (custom feature hooks)

Hook directories: compatibility/, custom/, features/ Hook registry: src/hooks/registry.ts

Types:

• compatibility — cross-version compatibility hooks
• features — feature-specific lifecycle events
• custom — user-defined hooks

Infrastructure layer (performance primitives)

• Session pool: 5 sessions per agent, max 10 reuse
• Work-stealing queue: Chase-Lev algorithm, LIFO/FIFO configurable
• Memory pools: Object (200 slots), String (intern), Buffer (4KB)
• MVCC state: atomic sync for shared state mutations
• Circuit breaker: 5 failures → open, 2 success → close
• Rust connection pool: 4 processes, 30s idle timeout

CLI entrypoint

/task "..." slash command via OpenCode CLI.

OpenCode Orchestrator — Uniqueness & Positioning

Differs from seeds

Closest to claude-flow in using a hierarchical Commander → Workers pattern with explicit orchestration roles. Key differences:

1. Single-tool target — OpenCode CLI only. Claude-flow targets Claude Code + Codex; aistack is multi-provider. This is the most narrowly targeted framework in the corpus.

2. Process-level performance engineering — Chase-Lev work-stealing queues, MVCC state synchronization, Rust connection pools, and memory pools are novel; no other seed framework ships low-level concurrency primitives. This reads more like a high-throughput server than an AI coding assistant framework.

3. Composable modular prompt assembly — system prompts are composed from 20+ named TypeScript constants joined at runtime, allowing per-agent inclusion/exclusion of behavior modules. No other framework in the batch takes this approach; most embed prompts as static strings.

4. Evidence-based mandate (AGENTS.md) — the most rigorous anti-hallucination protocol in the corpus, written as absolute prohibitions with a Korean-language author voice that suggests internal tooling repurposed for public release.

5. No MCP server — unlike claude-flow, aistack, or CAO, this framework operates entirely within the OpenCode tool execution loop. No external server.

Observable failure modes

• Single-tool lock-in: moving to Claude Code or Codex requires a framework rewrite
• MVCC and work-stealing complexity may introduce subtle concurrency bugs in edge cases
• Korean-language documentation limits community adoption
• No persistent memory means each /task starts from scratch

Competitive positioning

Targets teams running OpenCode who want production-grade concurrency patterns and strict evidence-based agent behavior. The performance engineering focus suggests it was built for high-volume task processing at scale, unusual for a single-developer framework at 167 stars.