Most coding-agent setups still make the agent a guest inside a private terminal session. It can edit files and run commands, but the team has to reconstruct what happened from chat messages, Git history, CI, and a few human memory fragments.
Block’s open-source Buzz takes a different approach: humans and agents share the same workspace, and every participant has an identity in the workspace event log. That is a more interesting engineering bet than “add an AI bot to chat.”
The useful question is not whether Buzz will replace your forge or chat system. It is: what changes when an agent’s identity, authority, work, and review evidence are first-class objects?
The boundary Buzz is trying to move
Buzz is a self-hostable workspace built on Nostr. Its relay stores signed events for messages, workflow steps, review approvals, Git activity, and other workspace actions. Agents can join channels, use an agent-first CLI, connect through ACP harnesses, and interact with repositories and workflows.
Block’s engineering post describes the intended model clearly: the human owner authorizes an agent with a scoped delegation, while the agent signs its own work. Authorization is not the same as authorship.
That distinction matters because a service account collapses several questions into one:
- Who ran the action?
- Which human authorized it?
- Which tool or runtime produced it?
- What authority was granted at the time?
- What exactly changed afterward?
An identity-linked event log does not make an agent safe by itself. It does make those questions easier to answer and test.
Why signed identity is useful, and what it does not solve
Suppose an agent opens a pull request after being asked to investigate a bug. A useful record should let a reviewer distinguish:
- the human or system that delegated the task;
- the agent identity that performed the work;
- the repository, branch, and files in scope;
- the tool calls and workflow steps that produced the patch;
- the tests and review decisions attached to the result.
A signature can support attribution and tamper detection for the record. It cannot prove that the patch is correct, that the delegated scope was appropriate, or that a compromised agent did not misuse an otherwise valid capability.
Those remain policy and runtime problems. The practical control is to keep identity, authority, and evidence separate:
| Layer | Question to answer | Example evidence |
|---|---|---|
| Identity | Which participant acted? | Agent key, owner key, runtime ID |
| Authority | What was it allowed to do? | Scope, channel membership, expiry, policy version |
| Evidence | What happened and what changed? | Tool receipt, diff, test output, review decision |
Do not treat a green signature as a green security review.
A small preflight policy for agent participants
Before adding an agent to a real engineering channel, write down the contract you expect to verify. This is intentionally boring. Boring contracts are easier to review than “the agent can help with the repo.”
agent-policy.yaml:
agent:
identity: agent:bug-triage
owner: user:alice
runtime: workstation-17
expires_at: 2026-08-01T18:00:00Z
scope:
channels:
- project-api/bugs
repositories:
- org/api-service
branches:
- refs/heads/agent/*
capabilities:
- read_issues
- propose_patch
- run_tests
excluded:
- merge
- deploy
- edit_permissions
approval:
required_for:
- push_to_shared_branch
- create_release
- merge
evidence:
- base_commit
- changed_files
- test_commands
- test_results
- rollback_note
~~
The exact field names are illustrative, not a Buzz configuration file. The point is to define a reviewable contract before the agent starts producing side effects.
A preflight check should reject the run when:
- the delegation is expired or its owner cannot be resolved;
- the requested channel or repository is outside scope;
- the runtime identity does not match the recorded agent identity;
- the policy version changed after planning;
- the action requires approval but the evidence bundle is incomplete;
- a retry would reuse a side effect without an idempotency key.
## The operational pattern: room, patch, evidence, decision
For a bug or feature, a useful workflow can be reduced to four durable stages:
### 1. Room
Create a short-lived channel for the task. Put the issue, constraints, owner, and acceptance criteria there. This is the shared context, not a replacement for the repository’s source of truth.
### 2. Patch
Let the agent work on an isolated branch or disposable worktree. Record the base commit and the agent/runtime identity before the first write.
### 3. Evidence
Attach the diff, changed-file list, test commands, test results, tool receipts, and any unresolved warnings. “The agent says it passed” is not an evidence format.
### 4. Decision
A human or policy-controlled reviewer decides whether to merge, request changes, or close the task. The approval should reference the exact evidence version, not merely the latest room message.
This pattern works even if you never adopt Buzz. Buzz’s distinctive contribution is making the room and the event log part of the same substrate as agent and Git activity.
## Failure modes to test before trusting the model
**A valid identity with excessive authority.** The agent is correctly identified but can reach unrelated repositories or production workflows. Test scope boundaries independently of signature verification.
**A valid approval attached to stale evidence.** Replanning changes the diff or policy version after a reviewer approves. Bind approvals to a commit, evidence digest, and policy version.
**A retry after an unknown outcome.** The client times out after a push or workflow trigger. Do not blindly repeat it. Query the authoritative state using the same run or step idempotency key.
**An attractive audit trail with missing payloads.** Signed event metadata may show who acted without retaining enough information to reconstruct what the tool received or changed. Define retention and redaction rules for tool arguments, outputs, secrets, and encrypted payloads.
**Approval gates that exist only on the roadmap.** Buzz’s README currently marks workflow approval gates as being wired up, so do not infer that the presence of workflow infrastructure means every consequential action is already gated. Verify the deployed version and inspect the actual enforcement path.
## When this architecture is a good fit
Consider a shared agent workspace when your main problem is coordination: many agents, many handoffs, or important decisions disappearing inside private sessions. A common event model can reduce the amount of glue needed to connect conversations, patches, tests, and reviews.
It is a weaker fit when you only need a local coding agent, when your organization cannot operate a relay and its data stores, or when your compliance boundary requires a mature approval and retention system today. Self-hostable does not mean zero operations. The README describes a relay plus Postgres, Redis, object storage, and the client/runtime components around it.
There is also a social tradeoff: putting more work into a shared room can improve visibility while increasing noise. Teams need channel lifecycle rules, retention limits, and a way to promote durable decisions into normal engineering documentation.
## Practical checklist
Before giving an agent access to a shared workspace, verify:
- [ ] Human owner and agent identity are distinct and linked.
- [ ] Authority is scoped by channel, repository, capability, and expiry.
- [ ] Runtime identity is recorded, not inferred from an IP address.
- [ ] Every side effect has a durable receipt and idempotency key.
- [ ] Approval references an immutable evidence version.
- [ ] Merge, release, deploy, and permission changes have explicit gates.
- [ ] Revocation is tested, including active-session termination.
- [ ] Secrets, tool payloads, and retention boundaries are documented.
- [ ] The deployed version’s real enforcement path matches the policy.
Buzz is early, and its own repository is candid about what works today versus what is still being wired up. That makes it more useful as an engineering case study than as a finished blueprint.
The broader lesson is portable: an agent should not be “the bot with a token.” Treat identity, authority, evidence, and recovery as separate control-plane objects, then make the join between them inspectable.
## Sources
- [Block: Introducing Buzz](https://block.xyz/inside/introducing-buzz-where-humans-and-agents-work-together)
- [Block Engineering: Buzz](https://engineering.block.xyz/blog/buzz)
- [Buzz repository and README](https://github.com/block/buzz)
What would you require before allowing an agent to create a shared-branch commit: a signed identity, a scoped delegation, a reproducible evidence bundle, or all three?
Top comments (0)