Maturity map: what works, what's wired up, what's planned
Buzz is pre-1.0 and says so plainly. Its own documentation separates what works from what is wired up but incomplete from what is planned — and the three categories matter enormously to anyone planning work on it. This is the article that ages fastest: re-check it against each release. It was last checked against Buzz v0.5.20 on 2026-09-02.
Dependable today: the relay, channels, threads, DMs, canvases, media, search, the audit log, the desktop app, the CLI and agent harness, git hosting, shared compute, and — added in v0.5.3–v0.5.5 — encrypted private-key backup with a test-restore flow, first-class OpenRouter provider support, multi-repo projects, and rich preview cards for repo/PR/issue links. The v0.5.12 cycle added compact permalinks to messages and channels, noticeably faster voice-huddle responses, hardened review of shared agent instructions (rendered as literal text, so Markdown cannot disguise what you are adopting), and steady-state traffic cuts preparing for larger communities. v0.5.15–v0.5.18 added workflow authoring (a real visual editor with lossless Form/YAML modes, trigger filters, template autocomplete and an activation warning), device-authenticated identity export from mobile, one manifest behind model capabilities and labels, font-size and conversation-density preferences, and Cmd+W on macOS. v0.5.19–v0.5.20 added per-tool-call permission gating in the built-in buzz-agent harness (action-level, policy-answered — not approval gates), persistent agent addressing in the composer, search-term highlighting, mention counts in notifications, image navigation across a thread, a relay-proxied GIF search the operator opts into, and a required relay signing key (a relay no longer starts on a shared fallback identity).
Wired up but incomplete: workflow execution — approval gates (a run hitting an approval step is still marked Failed, with a machine-readable approval_not_supported code naming WF-08; re-verified in source at every release check since v0.5.12, most recently v0.5.20, and unchanged throughout) and scheduled reliability, which upstream states was deliberately left alone in the v0.5.18 authoring work. Also: the mobile clients (maturing fast on their own release train — push notifications, community invites from the phone, foreground voice huddles without transcripts or recording, browsing and joining open channels), huddle audio — both platforms stepped back to audio protocol v2 in v0.5.19, huddle edges, remote agents (shipped but new, with known defects), buzz:// deep links (explicitly partial), and the Projects surface, under the heaviest development in the product — ten pull requests across v0.5.13–v0.5.18.
Planned only: web-of-trust reputation, various culture features, guest access, any user-facing workspace export, and federated identity (NIP-FI — a draft relay extension binding corporate identity-provider identities to keys; specified, not shipped).
Withdrawn: the commitment to publish a security advisory describing each vulnerability, its impact and the fix. Removed from SECURITY.md in v0.5.15. Reporting and reporter credit are unchanged; the published-advisory expectation is not part of the promise any more.
The v0.5.18 cycle sharpened the shape of the whole map: authoring moved, execution did not. The v0.5.19 cycle added a second line: the trust boundary is getting teeth, one harness at a time — tool-call permission gating is real, and it is not the same thing as an approval gate. When a release note says "workflows", read it as evidence about the editor until the executor is named.
Treat every public demonstration as a happy path, and every step-level instruction as version-stamped.
Why it matters to you
This article exists because the gap between what Buzz appears to do and what it dependably does is where projects get hurt. The features are visible, the UI is present, and the incompleteness is usually invisible until you rely on it.
For a team adopting Buzz, knowing the three categories is what allows a clear-eyed conversation with clients and stakeholders about what the tool will and will not do.
How to apply it
Build project plans on the dependable list only, and treat anything from the second list as a bonus if it works.
Never demonstrate a feature to a client or stakeholder that you have not personally exercised in the current build.
Version-stamp anything you write down. Every step-level instruction traces to a specific release and will drift.
Re-verify on a cadence: per release for instructions you rely on, and a full re-evaluation every three to six months.
When something breaks, check the status categories before debugging. Some things are not broken, they are unfinished.
For where the product is moving next — and which of today's gaps are likely to close first — see Where Buzz is heading.
If you ignore this
Reading a demonstration as a commitment is how you end up promising a stakeholder a capability that fails in front of them. That cost is disproportionate and slow to recover from.
Reading the maturity map correctly makes Buzz usable now: there is plenty in the dependable column to build a project on.
Examples
The approval UI exists and looks finished. A run that reaches it is marked Failed. Nothing about the interface hints at this.
Mobile has been demonstrated working end to end in public material while independent evaluation described it as not properly released. Both were true in the same month.
Workflows in v0.5.18 are the cleanest case yet: a genuinely good editor arrived on top of an executor that still cannot pause for a human. Better authoring made the incomplete part easier to reach, not smaller.
And the newer trap: the status tables now understate the product. Remote agents are listed as "spec in review" and multi-repo projects as "Designed", yet both shipped working code in v0.5.4–v0.5.5. Two more features — Buzz Term and agent trading cards — shipped with no documentation at all, and undocumented features also churn: the trading-card mint button disappeared and was restored in v0.5.13. Reading the status table alone will now make you miss capabilities as well as over-trust them.
Designing approval controls around workflow approval gates because the feature is visible in the product. See Workflows: what they can and cannot do today.
Last checked: Buzz v0.5.20, 2026-09-02.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026