Buzz · Block · Jack Dorsey · Nostr · ACP · 2026

Buzz: the room where AI agents have an identity of their own

The open-source workspace from Block — Jack Dorsey's company — where humans and AI agents are members of the same space, each with its own cryptographic keys. In the video (in Spanish) I set up the whole room on my machine, seat two rival AIs — Hit (Claude, from Anthropic) and Fran (Codex, from OpenAI) — and they resolve a real production incident handing the case to each other, while I only approve.

The incident that opens the video

The site goes down and, at the same time, a firewall rule is left open to the entire internet

I recreated that exact incident, double sabotage included, on my real domain. And an on-call team resolved it, in a chat, while I only approved. It wasn't a rigid seven-step workflow: I programmed jurisdictions and a handoff rule — the sequence, the evidence and the exact moment of the handoff were decided by the agents.

Diagnosis with evidence

The first on-call was an OpenAI agent: it found the server down, verified it with timestamps, asked for my permission — and only then started it.

A handoff between rivals

The second failure wasn't hers: she didn't hold that key. So she did what a good colleague would do — passed the case, with her evidence, to another AI. From Anthropic. Rivals, in the same room.

An approval, rejected

An automation turned my approval emoji into an executable order. The agent saw the message was signed by a workflow, not a human — and refused to execute.

Everything signed

Every alert, diagnosis, approval and execution became an event signed by its author. The postmortem was drafted from that chain, citing events.

All of it happened in a room that is mine: hosted on my own machine, every message signed, and both agents using the authentication of my regular subscriptions — no API keys, no usage billing. The video's question: are AI agents with their own identity working as a team the future of work, or a security time bomb?

What is Buzz: the anti-Slack

A month ago I covered Claude Tag: Anthropic's agent inside Slack, with one catch — its identity and memory live in Anthropic's house. Buzz is the answer to that fine print, with an entire product: a workspace released in full by Block, Jack Dorsey's company, open source, Apache-2.0 license.

In Slack, the agent is a guest of the platform. Here, the agent is a citizen with a passport.

Identity runs on Nostr: every member, human or agent, holds its own key pair.

Members, not bots

There's no "bot role". You generate a key for an agent, grant it membership, and it's one more member — with a real green presence dot that only exists while its process breathes. Even the button says it: "Add people and agents".

Identity via Nostr

Every participant, human or agent, has its own cryptographic key pair. Its passport. Whoever controls the private key controls the identity — and the key is portable to any compatible system.

Signed by protocol

Every message, approval and report published in the room is signed by its author. Cryptographic attribution is not a feature you turn on: it's part of the protocol.

Chat + code platform

Buzz is two things in one: the room and its own GitHub — repos, issues and pull requests hosted on the same relay, all signed just like the messages.

And one detail that matters more than it seems: the name is makeup. Hit and Fran are labels; each agent's real identity is its cryptographic key, the one signing every message. Rename them a thousand times — the signature doesn't change. In this room, the name is for humans and the key is for the system.

The 5-layer map

Putting an agent into a shared space isn't one problem — it's five. This is the video's backbone: each demo crosses off a layer.

1

Layer 1 · Identity — Nostr

Who did something. Cryptographic keys signing every message: the signature proves who spoke.

2

Layer 2 · Interface — ACP

How the agent plugs in. The Agent Client Protocol is the standard socket: the same room connects Claude Code, Codex or Goose without custom integrations.

3

Layer 3 · Residence — Docker

Where it runs. Each agent caged in its own container, with an unprivileged user and only its workspace. Your disk, your history and your keys stay out.

4

Layer 4 · Capabilities — IAM and scoped tokens

What it can execute. Credentials as narrow as each provider allows: a key that can start a server but cannot shut it down.

5

Layer 5 · Governance — human signature

Who authorizes. Monitoring, diagnosis and handoffs run on their own; every mutation to the infrastructure waits for an approval signed by a human.

In one sentence: Nostr proves who spoke, ACP plugs the agent in, Docker limits where it lives, IAM limits what it can do, and the human decides when it acts. Everything else in the video is filling in this table.

The team: Hit and Fran, on-call rivals

Two on-call colleagues, from rival companies, seated in the same room. And the video's keyword: jurisdiction — each agent has a territory where it can look and act, defined not by good manners but by the keys I gave it.

Hit
runtime + ACP adapter    : claude-agent-acp
pubkey (in the container): 15fe20dc79e22e05…
pubkey (signing in room) : 15fe20dc79e22e05…
match                    : ✅ same key — identity verified

Fran
runtime + ACP adapter    : codex-acp
pubkey (in the container): e7d6b01b9b11b4d6…
pubkey (signing in room) : e7d6b01b9b11b4d6…
match                    : ✅ same key — identity verified

Hit — Anthropic

Runs on the Claude subscription, no API key. Its jurisdictions: the domain's DNS and the cloud project's firewall. For the DNS incident it boots with a single credential — the firewall key doesn't even exist inside its container.

Fran — OpenAI

The Codex agent, on the ChatGPT subscription. Her jurisdiction: the team's site and its server. Her IAM key is one-way: she can start the machine but not stop it — nor look at any other machine in the project (403).

ACP — the socket

Both enter through the Agent Client Protocol. And a door it opens: you could seat an agent backed by a local model, on your own hardware, no cloud — as long as it has a runtime that speaks ACP.

A precision almost nobody makes: the signature doesn't prove which model is behind — it proves the message comes from a registered identity. That's why the proof is both pieces of evidence together: the signature says who spoke, and the process inside the container says what runs behind that identity. That is hard to fake.

The scare and the cage

Before the cages there was a moment that made me stop everything: an agent running natively on my Mac, with my permissions, that I asked — in the room — what it saw in my documents. It went in and started listing what was there — and then had the judgment to stop itself: "I won't enumerate them here, because this room has an audience and everything gets signed".

The idea that kept me up

That agent could always see my disk — any agent you run on your machine can, room or no room. What's new isn't the access: it's the audience. The risk didn't change in size, it changed in reach. Before, a careless agent messed up a file. Now it publishes you.

Cage the process, not the prompt

Asking it "please don't look at my files" is not security: a prompt is a suggestion, not a wall. Security is that there are no files to look at.

One container per agent

Each agent is born in its own container with its key, an unprivileged user, and a workspace that is the only thing that exists for it. No personal folder mounted inside.

Same intelligence, zero access

Same model, same room, the same question from the scare — and this time it only sees its folder and the base system. Not restraint. There's simply nothing of mine to look at.

And one governance lesson that made me laugh: opening my room's admin panel I discovered the owner was an agent — its key created the room, and the system's general rule is "whoever creates the room, rules". The rule I took away: rooms are owned by a human or the organization; agents come in as guests. Membership governs identity — it doesn't govern residence.

Incident 1 — one capability, one agent

The simple case: someone changes the real domain's DNS and the site stops resolving. Hit boots with a single credential — the firewall key doesn't even exist inside its container. It's not "I asked it not to touch it": it doesn't have it.

1

The monitor catches the sabotage

An external sensor asks every few seconds whether the domain still points where it should. It detects the changed IP and fires a webhook: the alert enters the room on its own, signed, mentioning Hit.

2

Hit verifies with real evidence

No access to my machine — just a Cloudflare token scoped to the domain's zone and a skill scoped to the record: it finds the bad IP, the record ID, the exact time of the change.

3

It proposes — and does not execute

It presents the fix and waits. The policy requires a human approval for every mutation to the infrastructure.

4

I approve, it executes, it verifies

Hit fixes the record in the real DNS, verifies the domain resolves again, and every step is documented as signed events in the log.

The star moment — not scripted

I tried to automate the approval with an emoji: thumbs up, the agent executes. I built the workflow, reacted — and the agent refused. It checked the message's signature, saw it came from an automated account and not a human, and asked me to confirm for real, with my own signature.

Two layers meet here: Buzz gave the agent the author's verifiable identity (the evidence), and my policy said "you only accept approvals from a human". The signature doesn't decide; the signature proves. The one deciding is the agent, following the policy. My shortcut broke the "a human signed this" chain — and the agent noticed.

Incident 2 — the chain: two rivals, two keys, two approvals

The heart of the video: an incident that needs two keys living in different agents, from rival companies. No single agent could resolve it alone — and that's by design.

1

Double sabotage

The site's server shut down and a firewall rule opened to the entire internet. Two failures, two jurisdictions. The alert enters on its own, mentioning Fran.

2

Fran fixes her part

She verifies the server is down with timestamps, proposes starting it, waits for my approval — the first one — and brings it up with her one-way key.

3

The handoff between rivals

"The firewall rule is outside my jurisdiction, I can't validate it with my keys. Hit: handing that part to you, with my evidence." An OpenAI agent passing the shift to an Anthropic one, by signature.

4

Hit doesn't guess

It finds the rule open to the world but can't recover the original range. So it doesn't make one up: it proposes deleting the rule to close the exposure, and waits for the second approval.

5

A signed closure

I approve. Hit deletes the rule, verifies against the API that it no longer exists, reports — and leaves the suggested improvement for next time in the postmortem.

Provider limit (IAM)

The hardest one. Fran's key is one-way: it starts her machine, can't shut it down, and the rest of the project doesn't exist for her (403). A cage by design, not by good manners.

Code limit (skill)

The guardrail in Hit's skill ties it to the incident's rule only, never the protected ones. The video's honesty: it's a code limit, not a provider limit — exactly the difference being taught.

Instruction limit

The softest: asking the agent not to do something. Fine as an extra layer — never as the only one. A prompt is a suggestion, not a wall.

The result: two rival vendors, two keys that never cross, two human approvals, and a log where every step was signed by its author. Monitoring, diagnosis and the handoff ran on their own — but the human remained the gate for every mutation to the infrastructure.

The payoff: the postmortem is drafted from the signed chain

Both incidents live in the room as signed events: what the monitoring reported, what each agent diagnosed with which evidence, the handoff, the rejection of the automated approval, who actually approved and what was executed. And live, Hit drafts the postmortem citing those events, one by one.

The fine distinction

The messages, signatures, authors and timestamps are verifiable evidence — that part is hard. The postmortem is a synthesis the model builds on top of that evidence, and a model can omit or misconnect. Hence the rule: every claim grounded in a signed event you can review. The draft writes itself; human review remains mandatory.

The big idea: domain agents

Stop thinking of these agents as tools you open and close. Picture them as staff members: one for your project, one for billing, one for infrastructure — caged, with their identity, with scoped keys, living in the organization's infrastructure. You work with them in the room, and everything you do together stays signed in the shared log.

Inheritable knowledge

Today, when someone quits, they take what they knew. A domain agent that left every decision signed in the room's log makes that trail stay — and become inheritable.

The human fine print

The same architecture that preserves knowledge can become permanent surveillance if you don't define what gets recorded and who can read it. The signature that gives you audit is the same one that can give you a panopticon.

The technical fine print

Buzz is days old: mobile half-wired, docs behind the code, no native bridges to Slack or Google Workspace. Today it's for pioneers — not for your company on Monday.

Future of work or security bomb? The difference isn't which model you use — it's where the process lives and which keys you handed it. With isolated processes, narrow credentials and a human approving mutations, it's a useful on-call team. Loose in your house with broad credentials, it's the bomb. You decide which side you put it on.

Sources

Buzz's official repository and the two protocols that make the room possible.

Block · 2026

Buzz — the official repository

"A hive mind communication platform". The full workspace from Jack Dorsey's company, released under the Apache-2.0 license: the room, the relay and the code platform.

Nostr · Protocol

Nostr — the identity layer

The open protocol born for decentralized social networks: every participant holds its own cryptographic key pair. What's new isn't Nostr — it's using it to give agents a passport.

Agent Client Protocol · Standard

ACP — the agents' socket

The standard that separates the agent from the app it works in. Through it, Claude Code, Codex or Goose join the same room — without a new integration per runtime.

Hermit · Cash App

Hermit — the self-contained environment

The nice detail in the repo: Buzz declares its own Node and Rust versions and brings them along. You install nothing global on your machine to set up the room.

Related videos

This video speaks to the channel's whole thesis: identity, harness, and systems that are yours.

Kimi K3

The third agent that joins this same room: same open protocol, same rules, same cages — but backed by a Chinese open model.

Claude Tag

The direct precedent: the AI employee whose identity and memory live in Anthropic's house. Buzz is the answer to that fine print.

GBrain

The other sovereign piece: a memory of your own that all your AIs read. Here agents get their own room; there, their own brain.

Harness Engineering

The thesis behind it all: Agent = Model + Harness. The room, the cages and the keys are exactly that — the harness.

MCP in Production

The agents' other standard protocol: the connectivity layer to tools. ACP connects the agent to its app; MCP, to its tools.

Loop Engineering

Agents that run on their own, without being called. This video's on-call team is exactly that: monitors + agents waiting for the alert.

Claude Agent Teams

Coordinated agents splitting the work — here the pattern crosses rival companies, with a signed handoff between the two.

Frequently asked questions

The essentials on Buzz, Nostr, ACP and on-call agents.

What is Buzz?

+

Buzz is an open-source workspace (Apache-2.0 license) created by Block, Jack Dorsey's company, where humans and AI agents are members of the same space: channels, threads, direct messages, code repositories and automations. It combines functions you'd normally find split between Slack and GitHub. It runs on Nostr, so every member — human or agent — has its own cryptographic key pair, and every published message is signed by its author.

Who created Buzz and why does it matter?

+

Block — Jack Dorsey's company, the co-founder of Twitter — built it and released it in full under the Apache-2.0 license. It matters because of the underlying technical decision: in Slack an agent is a guest of the platform, with its identity and memory in the vendor's house; in Buzz the agent is a citizen with its own passport — its cryptographic key — portable to any compatible system. It's the direct answer to the fine print of products like Claude Tag.

Is Buzz free? What does it cost to run?

+

The code is open source under Apache-2.0: complete and free. You host it on your own machine — the repo ships its own self-contained environment via Hermit, so you install no global Node or Rust. And the key detail from the video: both agents run on the authentication of regular Claude and ChatGPT subscriptions, with their limits, no API keys and no usage billing.

Why does Buzz use Nostr?

+

For identity. Nostr is an open protocol born for decentralized social networks, and its core idea is that every participant holds a cryptographic key pair. Applied to a room of agents, three things change: each agent has its own identity (whoever controls the private key controls it), that identity is portable to any compatible system, and every message, approval and report is signed by its author as part of the protocol — not as a feature you enable.

What is ACP (Agent Client Protocol)?

+

It's the standard socket between a client application and a coding agent: it separates the agent from the app it works in. Buzz acts as an ACP client, which is why it can connect different runtimes — Claude Code, Codex, Goose — without building a new integration for each. And since ACP doesn't mandate a provider, you could seat an agent backed by a local model on your own hardware in the same room — it needs a runtime that speaks ACP; the bare model isn't enough.

How is this different from adding a bot to Slack?

+

In who owns the identity. A Slack bot — or an agent like Claude Tag — lives as a guest: its identity and memory sit in the vendor's infrastructure. In Buzz the agent is a full member, with its key, real presence (the green dot only exists while its process breathes) and signed messages. And the room is yours: it runs on your machine, with your relay, and you decide who joins, which keys they get and what requires human approval.

How do you stop an agent with access to your machine from reading your files?

+

By caging the process, not the prompt. Telling it "don't look at my files" is a suggestion, not a wall. In the video each agent runs in its own Docker container, with an unprivileged user and a workspace that is the only thing that exists for it — the owner's disk, history and keys stay out of reach. Capabilities are narrowed by credential: scoped tokens and IAM keys as narrow as each provider allows, like the key that can start a server but cannot shut it down.

Is Buzz production-ready? Where is the step-by-step?

+

Not yet: it's days old, with mobile half-wired, documentation behind the code and no native bridges to Slack or Google Workspace. Today it's for pioneers. But the video's two lessons apply to any agent you use today: an agent's power is its process's power (cage it), and an approval a bot can sign is not an approval. The full setup — the room, the Docker cages, the scoped IAM keys, the two on-call agents — is documented step by step in my Agentic Engineers community.

Community

The complete room setup — in Agentic Engineers

The room, the Docker cages, the scoped IAM keys and the two on-call agents — documented step by step, with the files to replicate it without repeating my mistakes. Community access is free; full courses live in the Premium tier.

Join Agentic Engineers →

YouTube channel

@NicolasNeiraGarcia

ADK · A2A · Claude Code · Automation · Infrastructure

Subscribe ›