Buzz and the difference between a recorded decision and an authorized one

A team fixes a defect. An agent reviews the patch, another person reacts to the review, and somebody writes “ready to ship” in the project channel. A week later, the defect returns. The first question is not whether the message was saved. It is whether anybody with release authority checked the right commit, the relevant test results, and the conditions for deploying it. A well kept conversation can make that question answerable, but it cannot answer it on behalf of the team.

Buzz is Block’s open source workspace for people and AI agents. Its relay brings messages, review approvals, workflow steps, and Git events into a shared, signed event log. Agents can take part in channels instead of appearing only as notifications from another service. The project also provides a desktop client, an agent oriented command line interface, and an ACP bridge for runtimes including Goose, Codex, and Claude Code. Buzz is not a single model or a substitute for a deployment process. It gives participants a place to coordinate work and inspect its history.

Earlier articles in this series looked at collaboration and portable agent identity. A more operational question follows from those ideas: what does a signed record actually prove when the team must make a consequential decision?

Evidence is not authority

In Buzz, a comment by an agent and a response by a person use the same broad event model. The identity attached to an event helps the team trace who said something and where it belongs in the work. That is valuable when an engineer has to reconstruct why a patch was accepted. Instead of piecing together a chat thread, a repository notification, and a separate workflow log, the team can follow related activity in one workspace.

But the existence of an event is not evidence that the event’s author was entitled to approve a release. Nor does a signed “looks good” show which commit was reviewed or which tests passed. A useful decision record should name its object and scope. Which change? Which environment? Was the comment a code review, a product acceptance, or authorization to deploy? Each answer narrows the room for a false assumption.

The project’s own README draws a useful line between what works and what is still being connected. It lists the relay, channels, search, audit log, Git events, and YAML workflows among features available today. Workflow approval gates, however, are still being wired up. It would be misleading to treat a reaction or review approval in a channel as a guaranteed technical block on deployment. A visible approval record and an enforced release gate are different capabilities.

One patch, several decisions

Consider a hypothetical fix to a calculation on a customer facing dashboard. A coding agent prepares the patch. A review agent notices that a boundary condition is missing from the tests. A human developer adds a test and reruns the suite. A product owner confirms that the corrected result matches the expected business behavior. A release owner checks the commit and the test evidence before the change goes live.

All these participants may be in the same channel, but their decisions do not collapse into one approval. The review agent evaluated a code change. The product owner evaluated the expected behavior. The release owner evaluated the conditions for deploying. Even in a small team where one person wears multiple hats, it helps to state which judgment is being made. Otherwise “approved” can mean anything from “the screenshot looks right” to “the production rollout may begin.”

Buzz helps keep the conversation near the patch and the workflow events near the people discussing them. That reduces the chance that someone reviews one revision and another revision is shipped by mistake. The team must still implement its release conditions in the systems that perform the release. A channel history will not stop a pipeline if the pipeline has no check for the test result or authorized reviewer. Evidence in the workspace and controls in the execution path are complementary.

Membership is only part of access control

Buzz gives agents their own keys and channel memberships. Adding an agent to the right room can expose the context it needs without opening the entire workspace. For projects involving sensitive customer details, keeping that membership narrow is a sensible starting point. The signed history also makes it easier to distinguish what an agent posted from what a person posted.

Yet being allowed into a channel should not imply permission to run every available command. A triage agent that needs to read source files may not need production credentials. A review agent may need to inspect a patch without being able to merge it. An agent assigned to summarize incidents should not acquire broad access to customer records just because it joins the incident room. The runtime, repository, and connected services need their own permission boundaries. A conversational statement of policy is not an access control mechanism.

It helps to keep two kinds of records separate. An event log describes what happened. A role or policy definition describes what was allowed to happen before the event. The first is retrospective; the second guides and limits future action. If a person’s responsibilities change or an agent’s service permissions are reduced, yesterday’s signed conversation may remain accurate while no longer describing today’s authority. Teams need a place to maintain that current authority, not just a place to preserve historical messages.

A modest first test

Rather than moving an entire engineering organization into a new workspace, take a small change with a clear acceptance test. Identify the patch, the test result, the reviewer, and the person who can authorize release. Use Buzz to keep those events in the same project context. Then inspect whether the final decision refers to the exact change that was tested. If the answer cannot be reconstructed later, the record needs better links and clearer wording.

Test the unhappy path as well. What if the review agent leaves a concern unresolved? What if the test job fails after the reviewer posts a favorable comment? What if the release owner is unavailable? The team should be able to tell which step is blocked and who can resolve it. Where Buzz does not yet enforce a gate, the existing deployment system should continue to do so. This is less glamorous than replacing every tool at once, but it is a dependable way to discover the boundary between collaboration and control.

Buzz makes the reasons behind a team’s actions easier to find by giving people and agents a shared record. The organizational question of who owns each role and decision still needs an explicit home. agentic-organization addresses that adjacent layer as a self-hosted, file based platform for managing AI agents as first class members of an organization chart.