Orchestrators: Products Above the Runtime
The adjacent map contains 15 control planes. An orchestrator coordinates queues, isolated workspaces, or multiple agent sessions. Use one after a single runtime is no longer the bottleneck. Parallel runs multiply throughput, context drift, and review load at the same time.
The runtime/control-plane distinction also appears in Dax Raad's May 2026 OpenCode interview. He describes organization-wide provider setup, permissions, budgets, and rate limits as a separate control plane. That supports the architectural boundary used here, but it is not evidence that the enterprise product described in the interview is publicly available today.
| Control plane | Role | Loop ownership | Licence |
|---|---|---|---|
| AgentBox <small>★ 374 · 2026-08-23</small> | Runs multiple coding agents in parallel, each in its own sandboxed VM, locally or in the cloud, from one command. | No; evidence claimed | Open source |
| AgentsMesh <small>★ 2,330 · 2026-08-28</small> | The README documents a control-plane and data-plane system for operating external coding agents. | No; evidence confirmed | <abbr title="Not established from the pinned sources">?</abbr> |
| Autonomous Workstream <small>★ 32 · 2026-08-28</small> | The README documents a plugin and CLI that sequences bounded tasks through an external coding-agent backend. | No; evidence confirmed | <abbr title="Not established from the pinned sources">?</abbr> |
| Harness <small>★ 10 · 2026-08-28</small> | The README documents hardened container environments for agents rather than an agent decision loop. | No; evidence confirmed | <abbr title="Not established from the pinned sources">?</abbr> |
| cc-haha <small>★ 14,189 · 2026-08-23</small> | Local-first desktop workspace harness for Claude Code and other agents: multi-agent sessions, Git worktrees, code diffs, a skill marketplace, and chat-app access (WeChat... | No; evidence claimed | <abbr title="Not established from the pinned sources">?</abbr> |
| eigent <small>★ 15,083 · 2026-08-23</small> | Open-source desktop harness positioned as a local, free alternative to Claude Cowork and Codex: multi-agent workspace orchestration in a self-hosted app rather than a hosted... | No; evidence claimed | <abbr title="Not established from the pinned sources">?</abbr> |
| Agent Harness <small>★ 7 · 2026-08-28</small> | The README explicitly describes an adapter-driven control plane that delegates scheduling to the Codex runtime. | No; evidence confirmed | <abbr title="Not established from the pinned sources">?</abbr> |
| Harness CLI <small>★ 15 · 2026-08-28</small> | The README describes an orchestration and repair layer over Claude Agent SDK or Codex App Server runtimes. | No; evidence confirmed | <abbr title="Not established from the pinned sources">?</abbr> |
| Liza <small>★ 363 · 2026-08-28</small> | The source implements a control plane over external coding-agent CLIs, with a persistent YAML blackboard, isolated git worktrees, doer/reviewer roles, leases, recovery... | No; evidence confirmed | Apache-2.0 |
| Multica <small>★ 49,348 · 2026-09-09</small> | Human-agent work control plane that queues issue, chat, mention, and scheduled runs for external coding-agent CLIs through a daemon on a connected computer. | No; evidence confirmed | Restricted (multica license) |
| OpenAgents <small>★ 4,005 · 2026-08-28</small> | The official repository describes OpenAgents as a network for persistent agents and shared workspaces. | No; evidence claimed | Apache-2.0 |
| Proliferate <small>★ 310 · 2026-08-23</small> | Open-source AI IDE for Claude Code, Codex, OpenCode, and more. | No; evidence claimed | Open source |
| Symphony <small>★ 26,812 · 2026-08-23</small> | OpenAI's harness for fanning a task out into many isolated, autonomous coding-agent implementation runs and surfacing the ones that pass, so a team manages outcomes instead of... | No; evidence claimed | <abbr title="Not established from the pinned sources">?</abbr> |
| harness <small>★ 20 · 2026-08-28</small> | The README explicitly describes a unified subprocess wrapper for existing coding-agent CLIs. | No; evidence confirmed | <abbr title="Not established from the pinned sources">?</abbr> |
| vibe-kanban <small>★ 27,893 · 2026-08-23</small> | Kanban-style fleet manager for running Claude Code, Codex, or any coding agent across many tasks at once. | No; evidence claimed | <abbr title="Not established from the pinned sources">?</abbr> |
| Vigilante <small>★ 37 · 2026-08-28</small> | The README explicitly calls Vigilante a control plane over supported headless coding-agent CLIs. | No; evidence confirmed | <abbr title="Not established from the pinned sources">?</abbr> |
Liza: a repository harness and control plane combined
Liza coordinates external coding-agent CLIs rather than replacing their inner model-and-tool loop. Its pinned provider catalog defines nine subprocess adapters: Claude Code, Codex, Cursor, OpenCode, Gemini, Mistral, Kimi, Qwen, and Devin. Gemini and Mistral are disabled in that snapshot. This is why Liza appears in the adjacent map and does not increase the 42-runtime count.
The repository contains more than a prompt-level role description. The supervision model at commit a22c123 defines a persistent YAML blackboard, file-locked state changes, isolated git worktrees, lease and generation fencing, doer/reviewer task transitions, recovery operations, and supervised merge authority. The cloned snapshot contained 296 Go test files. Its exact commit passed the upstream Ubuntu and macOS jobs on 2026-08-27. Local tests were not executed for this review because the review host did not have Go installed.
The pinned INVARIANTS.md names system properties and their declared enforcement locations. The CONTRACT_FAILURE_MODE_MAP.md maps documented failure modes to contract clauses, and the snapshot tracks 28 modular skills. These artifacts make Liza's enforcement design inspectable. They do not measure whether the countermeasures improve agent behavior. The competitive survey's "Code Quality Evidence" is a project-published Claude Code assessment, so its grade is internal self-assessment rather than independent validation.
The satellite utilities are also optional, not runtime prerequisites. Liza's toolchain profiles can install Stacklit, scip-search, and functional-cluster tooling, while its agent tool contract falls back to rg, ast-grep, and direct reads when those indexes or tools are unavailable. This supports graceful degradation; it does not establish task quality.
The source confirms code-enforced orchestration, not production safety. A git worktree prevents concurrent agents from editing the same checkout; it does not isolate processes, credentials, or network access. Five of the nine provider adapters define an opt-in ACP path that passes --approve-all. OpenCode and Devin also use broad permission modes on their default CLI paths. For Codex, Cursor, and Qwen, the broad flag appears only on the ACP path; Claude's default path uses --permission-mode auto. Review the selected provider path, run Liza inside an OS-level sandbox with scoped credentials, and pilot recovery plus merge gates on real repository tickets.
Liza's own architectural issues ledger records remaining single-gate, cross-pair review, specification-feedback, and context-pressure risks. The separate Spec Evolution Protocol does provide procedural long-term synchronization through task blocking, human edits, a spec changelog, a spec_updated activity entry, and impact assessment. This protocol is human-driven rather than code-enforced, and the issue ledger still records missing automated lifecycle and staleness controls.
Loop and graph lens. Liza combines a frozen organization graph with a runtime work graph. The pinned pipeline.yaml declares roles, doer/reviewer pairs, state vocabularies, quorums, and cross-pair transitions. The supervisor creates and advances task dependencies at runtime. This is a domain-specific executable graph, not a general graph framework: the pinned TransitionDef exposes source, destination, trigger, and cardinality, but not a general edge schema, join policy, or arbitrary node program.
Judgment boundary. Mechanical checks can reject illegal state transitions, stale leases, missing dependencies, or an unmet review quorum. They cannot establish that the decomposition, implementation, or reviewer verdict is semantically correct. The same issue ledger says cross-pair decomposition judgment is a consequential single gate, provider diversity is preferred rather than guaranteed at verdict time, and reviewer accuracy is unmeasured. Manual checkpoints make human availability load-bearing only when auto_resume is disabled. With auto_resume, agents advance CHECKPOINT and COMPLETED states automatically. Pairing yolo pre-approves doer-side human prompts but retains reviewer approvals, validation, stop conditions, merge-conflict handling, and user stop instructions. Human authority remains load-bearing for governance and irreversible effects, even when live human availability is not an execution prerequisite. Compare Liza on two axes: workflow correctness and task correctness. Passing the first does not imply the second.
The evidence is no longer limited to the maintainer. An Ippon practitioner report describes a deliberately small catalog project with roughly 30 tasks, 5 automated sprints, 35 review verdicts, 3 corrected rejections, and 3 to 4 hours of human time. It also reports massive token consumption and required human planning checkpoints. This is a useful bounded REX, not a production or comparative benchmark.
Selection boundary. Liza is a candidate when a repository needs persistent multi-role state, code-enforced transitions, recovery, and supervised integration across many tasks. A bounded implementation-review loop has less coordination surface and should remain the default when those control-plane properties are unnecessary.
This responsibility-boundary reading was prompted by private comparison notes shared by Liza maintainer Tangi Vass. The published claims above are independently tied to the pinned repository rather than to those notes.