Chorus Agent Harness
A self-hosted AI-DLC harness for coordinating people and coding agents from idea through verified delivery.
Per-dimension scores and reasoning
Evidence shows a fine-grained permission matrix (5x3) and permission-gated MCP tools, but the default daemon permission mode is yolo (full access) and there is no explicit user confirmation mechanism. Data flow transparency is limited, sensitive data handling (e.g., API keys) is mentioned but not deep. Dependency security is not explicitly audited, external effects (e.g., daemon executing code) are documented but not fully discussed. Rollback mechanism is not explicit. Source attribution (e.g., OpenCode plugin) is mentioned but not verified. Thus, most criteria score 1 or 2.
Self-consistency is good, README aligns with code structure, tests cover key lifecycle scenarios. Dependency availability is documented (e.g., PGlite, external PostgreSQL) but not verified. Failure messages are covered by tests (e.g., retry on close failure), but overall reliability evidence is limited.
Audience is clear (AI-Human collaboration), scenarios are diverse (local, Docker, AWS). Capability boundaries are defined by permission matrix and docs, but trigger precision (e.g., daemon yolo mode) may be too broad. Environment fit has multiple deployment options but not verified.
Information architecture is clear, with multiple docs (PRD, architecture, MCP tools). Install notes are detailed, naming is stable (version numbers). Examples and FAQ are partial, known limitations are mentioned (e.g., PGlite concurrency). License is clear (AGPL-3.0), version changelog exists. Maintenance responsibility is not explicit, but community contributions are mentioned.
Output usability has UI and MCP tools, marginal value is high (AI-DLC workflow), cost-benefit is reasonable (local run without DB). But actual effectiveness is not verified.
Claims are traceable (README corresponds to code), cross-source verification is limited (only internal tests), fact-inference separation is good (docs distinguish design intent and implementation).
- Default daemon permission mode is yolo (full access), which may be too broad; users should explicitly configure permissions.
- No explicit user confirmation mechanism found; consider adding confirmation steps for high-risk operations (e.g., code execution).
- Dependency security is not explicitly audited; recommend checking for dependency vulnerabilities.
- Rollback mechanism is not explicit; consider providing data backup and recovery options.
What does this agent do, and when should you use it?
Chorus is a self-hosted agent harness that turns AI-driven development into a tracked workflow across ideas, proposals, documents, task DAGs, execution, and verification. Its product surface combines a Next.js web application, REST endpoints, SSE updates, and a permission-gated streaming MCP endpoint at /api/mcp. Approved proposals can materialize document and task drafts into workflow entities, while Kanban and dependency-DAG views expose progress and parallel work. The Chorus Daemon connects a local Claude Code, Codex, or Kiro CLI runtime to a Chorus server, with live transcripts and controls to inject instructions, interrupt, and resume. It can run locally with embedded PGlite or be deployed with PostgreSQL and Redis through Docker Compose or AWS CDK.
A team creates an Idea, performs structured requirements elaboration, drafts a Proposal, and produces documents plus a Task DAG before execution and verification. Actors receive permissions such as idea:write, proposal:write, task:write, or *:admin; Chorus exposes 50+ permission-gated MCP tools through /api/mcp. The Web UI and the chorus_search MCP tool use the same search backend. Running chorus daemon registers one or more local --cwd directories and wakes the chosen claude-code, codex, or kiro backend when Chorus dispatches work to that instance. The system records sessions, heartbeats, activity with session attribution, acceptance-criteria evidence, and real-time task and agent presence.
- A software team wants to turn an early product idea into reviewed requirements, a proposal, documents, and an executable task dependency graph.
- A Codex or Claude Code user needs a browser-based control plane that dispatches work to a precise local repository directory and streams the run.
- An engineering lead coordinating dependent implementation work needs both Kanban status and a DAG showing execution order and parallel paths.
- A team with review requirements wants agents to self-check acceptance criteria while administrators independently verify pass/fail evidence.
- An organization operating multiple coding agents needs resource-and-action-level permissions rather than fixed agent roles.
What are this agent's strengths and limitations?
- It models the full AI-DLC path—idea, proposal, documents, task DAG, execution, and verification—in one product workflow.
- Its daemon addresses individual agent/host/cwd instances and provides multi-directory serving, streaming transcripts, instruction injection, interruption, and resume.
- The 5-resource by 3-action permission model supports granular custom combinations instead of requiring fixed roles.
- It has documented paths from an embedded local database to Docker Compose and AWS CDK deployment.
- Embedded PGlite is intended for local single-user use; concurrent agents or users require external PostgreSQL or the full Docker Compose stack.
- The documented native daemon backends are Claude Code, Codex, and Kiro, so other coding CLIs do not have equivalent documented daemon support.
- daemon install relies on systemd --user on Linux; macOS and Windows receive a template for manual installation.
- A production multi-replica deployment adds PostgreSQL and Redis infrastructure to operate.
How do you install or deploy this agent?
For the simplest local install, run npm install -g @chorus-aidlc/chorus and then chorus. It automatically migrates embedded PGlite and opens http://localhost:8637; the documented default login is [email protected] / chorus. For local Docker deployment, run: [email protected] DEFAULT_PASSWORD=changeme docker compose -f docker-compose.local.yml up -d. Local development requires Node.js 22+ and pnpm 9+; without Docker, run cp .env.example .env, pnpm install, and pnpm dev:local.
How do you use this agent?
Sign in to the Web UI and use Settings → Setup Guide to connect an agent client, or create a cho_-prefixed API key in Settings → Agents. To attach a local runtime, run chorus login and then chorus daemon; for Codex, use chorus daemon --agent codex. To serve multiple repositories, run chorus daemon --cwd ~/work/repo-a --cwd ~/work/repo-b. Create an Idea, review its Proposal, assign resulting tasks to a connected agent instance, and monitor or verify the work from the Kanban, DAG, and session views.
How does this agent compare with similar options?
For local execution backends, Chorus directly documents Claude Code, Codex, and Kiro CLI. OpenCode support is provided through the community-maintained opencode-chorus plugin; no broader competitor comparison is documented.