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.23 on 2026-09-10.
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). v0.5.22–v0.5.23 added voice notes on desktop and phone, shareable teams in the community catalog with public descriptions on personas, a stated session model (one working context per channel, with a default-off experiment for one per thread), availability derived from relay presence with a Not managed on this device marker, squircle agent avatars with status and huddle indicators, restored quick reactions, the Pi harness preset, Databricks Unity Catalog model discovery, Operator and Moderator roles on the relay, enforced expiry on owner-to-agent authorisation, and inviting your own agents from a standalone forum.
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.23, 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, now at v0.16 release candidates — a first version of push notifications through a separate gateway, voice notes, 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 and still moving every release since. Federated identity (NIP-FI) belongs here now rather than under Planned: implemented relay-side in v0.5.22, operator-configured, and not yet visible in the client.
Planned only: web-of-trust reputation, various culture features, guest access, any user-facing workspace export, and information-flow control for agents — a v0.5.23 design draft and a generic library, describing a broker that would stop an agent from repeating what it read in a private channel into a wider one; design, not feature.
Not in the open-source build: a "Bestie" experience appears in the v0.5.22 release notes. It belongs to Block's internal, protected build — in the public app every Bestie component is a stub that renders nothing. Do not go looking for it.
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. v0.5.22 added a third: the product is preparing to be operated by organisations — enterprise identity went from draft to runtime, relay administration gained named roles, and authorisation gained expiry, all in one release, while nothing in the executor moved. 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.23, 2026-09-10.
Verified against Buzz v0.5.23 · Updated 10 Sep 2026