Chorus: an AGPL-3.0 harness that puts a permission gate between coding agents and your repository
The Agent Harness for AI-Human Collaboration, inspired by the AI-DLC (AI-Driven Development Lifecycle)
At a glance
- What is it?
- Chorus is a TypeScript task and session layer that sits above coding agents such as Claude Code, Codex and Kiro, letting agents propose work while a human verifies it. The interesting part is not the kanban board; it is the 5 by 3 permission matrix and the daemon that turns a laptop into an agent runtime.
- Who is it for?
- Adopt Chorus if you already run coding agents on a codebase where a human wants to sign off on proposals before tasks execute, and you accept an AGPL-3.0 server component in your stack. Skip it if your workflow is a single agent in a single terminal, since the harness adds a server, a database and a daemon you would not otherwise operate.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Chorus targets: agents that write code but cannot be held to a plan
A coding agent harnesses a model to write code. Chorus positions itself one level up from that, as the harness for a whole team of those agents plus the humans reviewing them. The problem it addresses is not code generation quality. It is the absence of a shared state machine around agent work: which idea became which proposal, which proposal produced which task, who is allowed to move a task from In Progress to To Verify, and what happens when an agent session dies mid-task. The README frames the loop as Idea, Proposal, Document plus Task DAG, Execute, Verify, Done, with each stage annotated by the permission an actor needs to act there. The intended user is a team that has already adopted agents and now needs an audit surface over them, not a solo developer trying an autocomplete tool.
Reversed Conversation and the 5 by 3 permission matrix
The design principle the README states is Reversed Conversation: AI proposes, humans verify. That inverts the usual chat pattern where a human writes a prompt and the agent answers. Here the agent drafts a PRD and a task DAG, and the human's job is verification rather than authoring. The mechanism behind it is a permission matrix described as 5 by 3, with no fixed roles. The workflow diagram labels each stage with the permission required: idea:write and elaborate for proposals, proposal:write for drafting, task:write and reports for execution, and *:admin for verification and closing. The README says any combination of the matrix works, and that a permission can be granted to a human, an agent, or both. That is a meaningful design choice. It means the same deployment can run with a human approving every proposal, or with an agent verifying another agent's task, and the difference is configuration rather than a different product. It also means the verification guarantee is only as strong as the permissions you actually assign. If you grant *:admin broadly, the human-in-the-loop property is nominal.
What the daemon actually does, and why it is the operational core
The Quick Start shows two commands: npm install -g @chorus-aidlc/chorus@0.17.1 followed by chorus. According to the README, that starts an embedded PostgreSQL via PGlite, runs migrations, and opens the app at http://localhost:8637 with default credentials admin@chorus.local and chorus. No database, Docker or config file is required for that path. The second piece is chorus daemon, which the README describes as turning your local machine into an agent runtime that picks up assigned tasks. The v0.16.1 release notes state that one chorus daemon can serve many independent agents at once, each with its own key, working directories, backend and permissions, configured through an agents[] array, and that agents can hand work to each other by @-mention. v0.15.0 added project-level agent working directories, where each user binds every agent in a project to a host and cwd, and the same target is reused across assignment, wake, resume and later turns. That last detail is the one that matters for reliability: a resumable session that loses its working directory is not resumable in any useful sense.
Connecting Claude Code, Codex, Kiro or an MCP client
The README points to Settings, Setup Guide as the fastest path. That wizard creates an API key and prints the exact commands for the selected client. The clients named are Claude Code, Codex, Kiro, dsh, OpenCode, OpenClaw, Pi, and any MCP-compatible agent. API keys are created under Settings, Agents, Create API Key. Several release notes describe this surface changing quickly: v0.14.1 added Amazon Kiro CLI as the fourth connection path with a one-command Kiro plugin via chorus agents add and a --agent kiro daemon backend; v0.16.4 added DeepSeek Harness through the @chorus-aidlc/chorus-dsh bundle, which drops skills, persona and MCP config into a dsh profile, and that release note explicitly says it is interactive for now with daemon wake coming later; v0.17.2 added chorus agents run for switching local agent profiles with one command. The pattern is a new client integration roughly every minor release, with daemon support arriving after interactive support. If you depend on a specific client, check which of the two modes it is in before planning around it.
PGlite by default is convenient and also the first thing you will outgrow
The embedded PGlite database is what makes the two-command start possible, and it is the clearest limitation in the material. The README itself qualifies the default: running multiple agents or deploying to production is directed to external PostgreSQL, Docker, or AWS via the deployment documentation. Nothing in the supplied material states a concurrency ceiling for PGlite, so I cannot tell you where it breaks. What I can say is that the project treats the embedded path as a local convenience and the external path as the production one, and that the v0.16.1 change to serve many independent agents from a single daemon is exactly the workload that pushes against an embedded single-node store. A second constraint is the daemon model itself. Agents are woken into directories on a host, and v0.15.0 describes browsing only daemon-approved roots. That is a sensible boundary, but it means the set of directories an agent can touch is a configuration artifact you have to maintain, not something the agent discovers.
How Chorus differs from running agents directly or using a CI-driven orchestrator
The obvious alternative is not another agent harness. It is the plain workflow most teams already have: run Claude Code or Codex in a terminal, review the diff, merge. That approach has no task DAG, no permission matrix, and no persistent state between sessions, but it also has no server, no database and no daemon to operate. The difference in approach is where the state lives. In the terminal workflow, the plan exists in the conversation and in the developer's head. In Chorus, the plan exists as a Proposal with a Document and a task DAG, and the README's Project Resource Graph renders ideas, proposals, documents and tasks as one connected tree with card statuses updating live. The second alternative is a CI-driven orchestrator that triggers agents on pipeline events. Chorus is not event-driven in that sense. It is assignment-driven: a human or an agent assigns an idea to a directory on a remote agent, and the daemon picks it up. If your work is naturally expressed as pipeline stages over commits, Chorus's idea-to-proposal-to-task model will feel like an extra layer rather than a fit.
Licence, release cadence and the cost of staying current
Chorus is licensed AGPL-3.0, which is the single most consequential fact for anyone planning to self-host it inside a company. The AGPL network clause is the part to read carefully with your own counsel; I am not giving legal advice, and the material here does not discuss how the project interprets the licence for hosted or modified deployments. On cadence, the release history is dense: v0.17.1 on 2026-09-01, v0.17.2 on 2026-09-04, v0.17.3 on 2026-09-07, with the repository's last push on 2026-09-10. Three patch releases in seven days suggests active maintenance, and it also suggests that pinning matters. The Quick Start itself pins a version in the install command, @chorus-aidlc/chorus@0.17.1, which is the right instinct. The upgrade cost is not the npm install. It is the client integrations, which have been the fastest-moving surface: Kiro in v0.14.1, dsh in v0.16.4, Pi in v0.17.2. Each one changes the commands your developers type and the daemon backend in use, so a version bump is a coordination task across every connected client, not a background update.
Editorial conclusion
Adopt Chorus if you already run coding agents on a codebase where a human wants to sign off on proposals before tasks execute, and you accept an AGPL-3.0 server component in your stack. Skip it if your workflow is a single agent in a single terminal, since the harness adds a server, a database and a daemon you would not otherwise operate. Before committing, verify three things on your own machine: that `chorus` comes up on port 8637 with the embedded PGlite database, that your agent client appears in the Settings, Setup Guide wizard, and that the daemon picks up an assigned task from a working directory you approve. If the daemon cannot reach your repository layout, the rest of the product does not matter.
Community notes