Agent Orchestrator Evolution Plan: Adding an AO-Style Control Plane on Top of chong

Forum topic · ✨步子哥 · 2026-05-29

Summary

This post compares the agent-orchestrator (AO) project with chong, a coding agent platform, and proposes an evolution roadmap. AO leads in multi-agent parallel delivery orchestration: canonical lifecycle modeling across session/PR/runtime/activity states, a reaction engine with retry/escalation semantics, first-class workspace and runtime management with hash-namespaced isolation, clean Tracker/SCM/Workspace/Agent/Notifier provider contracts, and an attention-first operator dashboard. chong instead has a stronger agent kernel: SessionAgent, subagent executor, task service, hooks, plugin system, scheduler, permission v2, session memory, A2A, and a Lua-first configuration approach. The author argues chong should not rewrite its kernel but add a new orchestration control plane above it: an OrchestratorService with planner, canonical lifecycle manager, reaction engine, workspace manager, provider layer, and attention queue, backed by SQLite persistence and exposed via a TUI-first operator console. Configuration favors Lua tables over YAML DSLs. A six-phase roadmap covers design freeze, a GitHub-first MVP, lifecycle/reaction closed loop, restore/archive/gc, operator console, and planner-driven automation, with risk mitigations for state divergence, automation overreach, API rate limits, workspace bloat, and hollow UI-first development.

This post analyzes the gap between agent-orchestrator (AO) and chong and lays out a detailed evolution plan. Rather than a full translation of the long design document, below is a structured summary of its key points.

Key points

Verdict: chong is stronger as an *agent kernel and execution substrate* (SessionAgent, subagent pool, skills, hooks, permission v2, scheduler, A2A, Lua-first). AO is stronger as a *multi-agent parallel delivery control plane* (issue → branch → PR → CI → review → merge → recovery → notification as a closed loop).
Recommendation: don't rewrite the kernel — add an Orchestrator control plane on top of it.

Where AO is ahead

1. Canonical lifecycle — session/PR/runtime/activity/reason modeled as orthogonal state, enabling decisions like "CI failed but agent alive" or "review pending but session idle" without stuffing everything into one status field. 2. Reaction engine — orchestration-event-triggered rules (not generic hooks) with send-to-agent/notify/auto-merge actions, retry budgets, escalateAfter, dedup, and oscillation debouncing (e.g., flapping ci-failed). 3. Workspace/runtime as first-class objects — per-worker git worktrees, project-scoped runtime dirs with hash namespacing, restore/adopt/archive/gc semantics. 4. Narrow, hard provider contracts — Tracker (issue semantics), SCM (PR/CI/review/mergeability), Workspace, Agent, Notifier interfaces prevent scattered GitHub/GitLab/Linear integrations. 5. Operator console — attention-first dashboard for supervising 10–30 parallel workers, reducing human polling cost.

chong's reusable foundation

Existing assets include internal/agent/subagent (worker pool, task state machine, worktree management), task service with CRUD/events, hooks, plugin loading, persistent scheduler, permission v2, session goal/todo injection, A2A, and a Lua-first config route. Gaps: execution-state-only state machines, no project/PR view, no orchestration-semantic reactions, no global workspace namespace or restore protocol, no operator-first multi-worker UI.

Target architecture

Three layers:

Execution layer (keep as-is): SessionAgent, subagent executor, task service, hooks, permission v2, scheduler.
Orchestration layer (new): planner, lifecycle manager, reaction engine, workspace lease manager, tracker/SCM adapters, attention queue, restore/reconcile service — backed by SQLite tables for projects, work items, worker sessions, lifecycle snapshots, reaction attempts, attention events, workspace leases.
Operator surface (new): /orch command group, TUI board sorted by attention (Needs Action / Working / Review Pending / CI Failed / Mergeable / Done), later RPC/Web.

Core design elements:

New first-class models: OrchestratorProject, WorkItem, WorkerSession, CanonicalLifecycle, PRSnapshot, ReactionPolicy, AttentionEvent, WorkspaceLease, AutomationAttempt.
Lifecycle states such as queued, spawning, working, needs_input, stuck, ci_failed, review_pending, changes_requested, merge_conflicts, mergeable, merged, done, terminated — each with reason, evidence, timestamp, and source.
Reaction actions: send_to_worker, notify_operator, pause/resume_worker, request_permission, open_followup_item, attempt_merge, archive_session — with retry budgets, escalation, fingerprint dedup, and audit logs.
Project-level runtime root (~/.chong/orchestrator/{hash}-{project}/) with sessions, workspaces, archive, metadata.
Provider interfaces: TrackerProvider, SCMProvider, WorkspaceProvider, ExecutionProvider, NotifierProvider; GitHub-first MVP implements github-tracker, github-scm, git-worktree-workspace, internal-agent-executor, desktop-notifier, tui-surface.
Config: global toggles in crush.json; project orchestration rules in .chong/orchestrator.lua (Lua tables, no new YAML DSL).
Structured activity events consumed by UI and reactions, falling back to JSONL/terminal parsing only for external runtimes.

Roadmap

Phase 0: design freeze, types, SQLite migration draft, /orch skeleton.
Phase 1: GitHub-first MVP — spawn one worker from an issue, track basic states.
Phase 2: lifecycle + reaction closed loop — CI failures and review changes auto-flow back to workers; escalation to operator.
Phase 3: restore, adopt-existing-workspace, archive/gc, reconciliation — long-lived system, not a demo.
Phase 4: TUI operator console with attention queue and quick actions (pause/resume/retry/restore/merge/archive).
Phase 5: planner — backlog ingest, work-item DAG, concurrency budgets, merge policy, controlled auto-merge.

Risks and mitigations

State divergence: orchestrator's canonical lifecycle is the sole source of truth; other states are inputs only.
Automation overreach: dangerous actions gated by permission v2; auto-merge off by default.
API rate limits: batch enrichment, webhook-first with polling fallback, caching and backoff.
Workspace bloat: leases + archive + tiered gc.
Hollow UI-first delivery: build lifecycle/reaction/restore before rich UI.

Final stance

The right path is to keep chong's agent/subagent/hooks/permissions/Lua strengths, add a project-delivery orchestration control plane with a GitHub-first, TUI-first, Lua-first approach, and land lifecycle + reactions + workspace restore before broad UI — potentially surpassing AO via deeper kernel control, programmable hooks/permissions/memory, natural Lua workflow expression, and stronger A2A/MCP/skill ecosystem integration.