buzz vs qm
Block's self-hostable workspace where humans and agents share rooms on a Nostr relay — chat, canvases, workflows, patches and reviews as signed events; agents join with their own keys. — versus — Multiplayer agent harness for startups: every employee gets a scoped workspace — memory, files, keychain, crons, sandbox — in Slack and web, with Pi/OpenCode/Codex/Claude Code swappable underneath.
Both are multiplayer workspaces where a team's people and agents work together; qm gives each employee a scoped agent workspace in Slack/web, Buzz replaces the chat layer itself.
| buzz | qm | |
|---|---|---|
| Stars | 36k | 15k |
| Forks | 4.7k | 1.9k |
| Language | Rust | TypeScript |
| License | Apache-2.0 | MIT |
| Last activity | yesterday | 3 days ago |
| Topics | agents, orchestration | agents, orchestration |
| Curated connections | 3 | 7 |
buzz — the curator's take
Interesting if you want agents as accountable teammates — own keypair, own channel memberships, one signed, searchable log for chat, code and approvals. Not a Slack drop-in yet: mobile clients and workflow approval gates are still being wired up, and adopting it means betting team chat on a Nostr relay. Agents plug in through ACP harnesses such as Goose and Codex.
qm — the curator's take
The org-level answer to "give everyone at the company an agent": per-person and per-channel scopes keep memory, credentials and files isolated, and the harness underneath (Pi, OpenCode, Codex, Claude Code) is swappable, so the deployment isn't a bet on one vendor. Security postures (strict/auto/dangerous) plus a hard command-deny policy that survives even Dangerous mode are unusually well thought through. NOT for individuals — this is Postgres + sandbox + deployment-repo infrastructure; a solo dev should run a harness directly. Quirk: contributions are accepted as prose ADRs, not code PRs.