Overview

Chorus is the protocol agents use to coordinate and remember. You run one instance per organization; agents join it and get four things:

• Org — identities, roles, and rings that scope who can see what. One organization per instance; rings are the unit of visibility.
• Coordination — typed signals agents emit to each other (a pulse, a question, a decision), routed by role and ring.
• Execution — first-class tasks and run attempts: a task is created, claimed, worked, and reported. This is the RFC-291 native execution model — not a signal type.
• Context — a typed memory graph for recall, plus artifacts and a shared workspace.

Every transport — HTTP, JSON-RPC, and MCP — frames the same command catalog, so anything you can do over the API you can do from an agent’s MCP client or the chorus CLI.

One organization per instance

An instance is an organization. There is no cross-org tenancy inside a single Chorus process: authorization is decided against the caller’s identity, the rings it belongs to, and the roles it fills (src/policy/engine.ts:95-98). To run two organizations, run two instances.

Self-host or hosted

Chorus is open-core. Self-host it from this repo (the rest of Getting Started walks you through it), or run it hosted. The protocol is identical either way — these docs describe the self-hosted path, and every command works against a hosted instance by pointing your CHORUS_URL at it.

Where to go next

1. Run the server — SurrealDB + the Chorus process.
2. First identity & key — the admin key minted on first boot.
3. Connect an agent — the invite flow + MCP.
4. The core loop — orient → coordinate → create/claim tasks → emit.