Where Buzz is heading
Outlook — direction, not commitments
This article is interpretation, not documentation. It reads the release trajectory (v0.5.3 → v0.5.20) together with Block's own vision files (VISION.md and the VISION_*.md set in the repository) and describes where the product appears to be going. Nothing here is a shipped feature unless the linked article says so; anything here may change, slip, or never arrive. Last checked: Buzz v0.5.20, 2026-09-02.
Most of this guide describes Buzz as it is. This article describes where it is pointed — because for anyone planning a project on a pre-1.0 product, the direction of travel decides what to build on now, what to wait for, and what to design around permanently.
There is a specific reason the vision files are worth taking seriously as a predictor. Since v0.5.12, Block requires its own managed agents to read VISION.md and the relevant VISION_*.md before planning any non-trivial change, on the stated grounds that "a locally correct change can still be wrong if it works against that direction." A team that steers its own development by those documents will tend to ship what they describe. Reading them is the closest thing to a roadmap Buzz has.
Six lines of movement stand out.
From chat app to work graph. Projects v3, buzz:// deep links for repos, projects, issues and PRs, permalink chips on messages and channels, agent CLI commands that return links: everything in the workspace is becoming addressable. This is where the engineering is actually going — ten Projects pull requests across v0.5.13–v0.5.18, with the work on main now about making the surface cheap to render, which is what you do to a surface you expect people to live in. The Projects vision goes further — a Nostr-native forge where "the branch channel is the pull request, the CI dashboard, and the discussion thread", merges require cryptographically signed approvals, and "bug report to merged patch" happens in one place, one search index, one identity system. This surface is the fastest-moving part of the product and explicitly partial today, which is why this guide describes it here rather than in a task guide — expect one once it settles.
The trust boundary is hardening piece by piece. Literal-text review of shared agent instructions, mention authorization enforced at the send boundary, two-step approval for destructive community actions, a moderation model where "reports are signals, never triggers". The direction is making who may instruct an agent, and what an agent may do, enforceable in the product rather than by convention. v0.5.19 delivered the first real piece: per-tool-call permission gating in the built-in buzz-agent harness, answered by client-side policy. That is action-level control on one harness — not workflow approval gates, which remain unmoved — so an agent's instruction is still the enforcement at the level of decisions. Expect the "by convention only" framing in this guide to keep softening as more of this lands; the identity story is next, with a draft federated-identity extension (NIP-FI) that would let an organisation's identity provider bind to Nostr keys.
Reliability becomes visible, then well-authored, before it becomes real. Authoritative run history, machine-readable workflow error codes, output-truncation recovery, and an activity-feed vision whose stated job is to "earn delegation" and whose rule is "never go dark". The pattern is observability first, surface second, function later. v0.5.18 added the middle stage to this reading: workflows gained a full visual editor, structured trigger filters, template autocomplete and an activation warning, while the executor was left explicitly untouched. For planning purposes: expect "silent failure" → "visible failure" → "well-authored failure" → "works", and do not read movement in the first three as progress on the fourth. Approval gates (WF-08) have sat unmoved at every release check from v0.5.12 to v0.5.20 while everything around them was rebuilt.
Scale for bigger, longer-lived communities. Steady-state relay traffic cut, presence scoped to demand, render churn fixed, voice-turn latency cut to a third. The core vision states the target plainly: one relay as an entire workspace for on the order of ten thousand humans and fifty thousand agents, with voice as a first-class surface rather than a gimmick. The current sweet spot — small teams — is the starting point, not the ambition.
Mobile graduates from window to peer. Its own release train, community invites from the phone, shipped push notifications with a privacy-preserving design, store-and-forward delegation, the phone as a key-recovery device — and, on main, foreground voice huddles with native audio on both platforms. The v0.5.15–v0.5.18 window touched over two hundred mobile files. Identity export from the phone is now gated behind device authentication, which is the kind of change made to a client people actually carry. The phone is still a control surface rather than a place agents run — but it is being invested in as a full client, faster than the earlier material suggested.
Agents become independent of any one machine. The remote-agents vision is explicit: identity lives on the relay, bodies are replaceable — "none of it dies with the machine". The mesh vision extends the same trust boundary to compute: "your community is not just where agents talk, plan, and leave records. It is where they can run." Together with the sovereignty end-state — "one domain, one identity, everything in one place — and it's yours" — the direction is a workspace whose people, agents, code and compute all sit behind a single membership decision.
Why it matters to you
The maturity map tells you what to build on today; this article tells you which of today's gaps are likely to close and which trade-offs are permanent. That distinction changes decisions. A gap on the roadmap (approval gates, Projects polish, mobile depth) is worth designing a temporary workaround for. A trade-off that follows from the architecture (relay latency, operator-readable content, pull-first attention) is worth designing around permanently, because the vision files treat these as choices, not defects.
It also changes how you read releases. Knowing that observability ships before function, you will not mistake a new error code for a fixed feature — and knowing the vision files predict the next wave, you can check them before promising a client anything about "soon".
How to apply it
Build on the dependable column of the maturity map only; use this article to decide which workarounds to build cheaply because they are temporary.
Before a client conversation about Buzz's future, check the vision files themselves rather than quoting this article — they are the primary source and they move: VISION.md, plus the themed set (Projects, Sovereign, Agent, Activity, Mesh, Moderation, Remote agents).
Treat everything in this article as hypothesis with a shelf life. It was last checked against v0.5.20; each release either confirms or bends these lines.
Read release notes for which layer moved. "Workflows improved" in v0.5.18 meant authoring, not execution, and the difference decided whether an oversight design was safe to build. Ask which layer before you act on a release note.
If you ignore this
You will either over-invest in permanent solutions to temporary gaps — elaborate approval machinery the product is about to make redundant — or under-invest in the permanent trade-offs, promising a stakeholder that latency or operator access "will surely be fixed" when the vision files say plainly that they are the price of the design.
Examples
WF-08 approval gates: the schema, API and UI shipped early, v0.5.12 added a structured failure code, v0.5.18 rebuilt the entire authoring experience around it, and the executor still does not wait. Read as trajectory rather than as a snapshot, this is a feature that has sat in the stages before "works" at every release check from v0.5.12 to v0.5.20 — still worth a cheap manual workaround, and that long is long enough that "cheap" should be taken seriously.
Treating relay round-trip latency as a bug that a future release will remove. The vision files describe the relay as the workspace; the latency is the cost of everything else on this page, and no release is coming to remove it.
Last checked: Buzz v0.5.20, 2026-09-02.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026