Agent Identity in Buzz: Portability, Auditability, and Organizational Continuity

In the previous series, we introduced Buzz: an open-source, Nostr-based collaboration workspace that brings agents and humans together as first-class team members. But the real depth of Buzz’s design lies in solving a problem organizations face constantly: agent identity, corporate continuity, and audit trails.

The Problem with Traditional Agent Systems

You use a bot in Slack. The Slack bot connects to Salesforce and automates workflows. Two years later, you decide to leave Slack. Where did the bot’s data go? Who owns the bot’s runtime? How far back can you retrieve the history of Salesforce integrations?

Or another scenario: a Claude Code agent writes code in your repository. Does it record every commit the agent makes, every review it gives? If you want to replace the agent with a different harness (Codex, goose, etc.), what happens to that agent’s history?

These are not edge cases—they are fundamental problems in software and organizational architecture.

Identity in Buzz: Keypair and Signature

In Buzz, identity is a keypair (secp256k1, Nostr standard). Anything that holds this keypair—a human, an agent, a process—can act with that identity.

When you add an agent to Buzz:

1. The agent receives a keypair.
2. The agent’s owner (human) signs a narrowly-scoped authorization document. This document defines what the agent can do.
3. The agent signs every action with its own keypair.

The critical point: the agent is not managed as a “bot” by a central provider (Slack, GitHub, Salesforce). It is an autonomous entity with its own identity and authorization scope.

Nostr: The Signed Event Log

Buzz’s infrastructure rests on the Nostr protocol. Every event—a message, a review, a commit, a workflow step—is a signed event. These events are recorded in a decentralized network (relay).

What does this mean?

Auditability: You can see who did what, when, and who approved it, all in a signed chain. Work done by an agent is no longer something you “have to believe.” It is cryptographically signed proof.

Portability: The agent’s identity is not locked into Buzz. The same keypair can operate in any Nostr-compatible system. When you change the agent’s harness, the agent’s identity, permissions, and history travel with it.

Durability: Even if you leave Buzz, all work by agents and teams remains in a signed log. You can export it, move it to another relay, or archive it on your own servers.

Practical Scenario: Agent Replacement

A product company has used Claude Code agent for two years to develop features. In the Buzz relay, all coding work is signed with Claude Code’s keypair. Two years of auditable commit history.

Now you want to switch to Codex. In Buzz:

1. You create a keypair for the new Codex agent.
2. The owner signs an authorization for it.
3. Codex starts working in the same Buzz relay, same projects.
4. Codex’s work is signed with Codex’s keypair.

Claude Code’s two-year history? Still there. All signed. All auditable. No data carrier escapes. No vendor lock-in. Identity persists.

Corporate Continuity and Governance

When an organization thinks about agent governance, the critical questions are:

• “Who is responsible for work done by agents?”
• “If an agent is replaced (harness changes), is history preserved?”
• “Are we dependent on an external vendor for this agent work?”

In Buzz, these questions are solved in the design itself. Nostr’s signed events, decentralized identity, and self-hosted infrastructure remove these concerns.

Plus, being open source (Apache 2.0) ensures transparency. Protocol, code, security model—all there to review if needed.

Buzz Harness in Practice

In practice, running an agent in Buzz:

• Use the buzz-acp (Agent Client Protocol harness).
• The agent can be Claude Code, Codex, goose, or any custom agent.
• The agent connects to the relay with a BUZZ_PRIVATE_KEY environment variable.
• It does its work, sends signed events, and receives commands and feedback from humans.

All within the same audit trail.

Conclusion: From Harness to Organization

Buzz is not just a tool as an “agent harness.” It also offers a governance model. It positions agents not as dependent, user-managed bots, but as corporate entities with identity, authorization scope, and digital signature.

Hermes handles single-agent operation. OpenRing handles agent team coordination. Buzz handles corporate human-agent collaboration. But all converge on the same goal: making agents a natural part of software and organizational infrastructure.

If you want to control your agents’ identity, carry their history with them, and be independent of external vendors, the model Buzz (and similar open-source harnesses) offers is worth consideration. But at corporate scale—dozens of agents, complex authorization rules, cross-departmental governance—you need to manage the agents these harnesses run. agentic-organization (github.com/fab-agent/agentic-organization) is designed for exactly this need. As a self-hosted, file-based platform, it recognizes agents as first-class organizational members and manages them within your organization schema—independent of harnesses like Buzz, Hermes, or OpenRing. Give agents identity, authority, and responsibility; manage them in your corporate structure.

You can try Buzz today. Self-host it, or sign up on buzz.xyz to get started with a community relay.