Buzz: como um agente de IA vira membro do canal com chave e trilha de auditoria próprias

Fala aí, beleza? Um agente de IA entrando no canal com a chave DELE muda bastante coisa, porque cada ação passa a ter dono de verdade, em vez de ficar pendurada no token de um humano que por acaso estava logado

Esse é o pulo do gato do Buzz, a plataforma de chat de equipe da Block (empresa de Jack Dorsey), anunciada publicamente em 21 de julho de 2026 e posicionada como concorrente de Slack e GitHub

Ele é open source sob licença Apache-2.0, com código no repositório oficial da Block, e a proposta é fácil de enunciar e estranha de digerir: humanos e agentes de IA nas mesmas conversas, com o mesmo tipo de identidade 🙂

Bora entender como isso funciona por dentro?

Por que o agente entra pelo mesmo caminho de uma pessoa:

Primeiro o alicerce, porque sem ele o resto não faz sentido

O servidor do Buzz é um relay Nostr

Que relay? É o servidor que recebe e distribui os eventos assinados do protocolo Nostr

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

E aqui está a parte interessante: cada mensagem, reação, passo de workflow, aprovação de review e evento de git vira um evento assinado gravado em um único log, seja o autor uma pessoa ou um processo

Cada participante do Buzz, humano ou agente, tem um par de chaves criptográficas que pertence a ELE, não à plataforma

Ou seja, o escopo vem da identidade, não de uma flag de permissão colada em cima de um bot genérico

Quem já montou agentes de IA com n8n conhece bem o padrão contrário: o agente age com a credencial de alguém, e no fim ninguém sabe direito se aquela ação foi da pessoa ou do robô dela

No Buzz, adicionar um agente a um canal é o mesmo procedimento de adicionar uma pessoa

Os papéis de membro que existem hoje são Owner, Admin, Member, Guest e Bot

Repara na sutileza: o papel se chama bot, mas o caminho de entrada é o de um membro, com chaves próprias, participações de canal próprias e trilha de auditoria própria

E tem mais um detalhe que muda o desenho inteiro: a participação no canal é o ÚNICO mecanismo de controle de acesso do Buzz

Os cinco papéis ali de cima existem, mas o que decide se tu lê e escreve num canal é estar dentro dele, e nada além disso

Quem é membro lê e escreve naquele canal

Quem não é, tem a requisição rejeitada pelo relay

Simples assim, e é exatamente isso que abre o caso de uso mais legal, que eu mostro logo abaixo

Como dar chave e permissão próprias a um agente no Buzz:

A sequência é curta, mas tem dois pontos onde dá pra se ferrar feio

Vou marcar cada um deles

1. Gere o par de chaves Nostr do agente com a ferramenta buzz-admin

Esse par é a identidade do agente dentro do Buzz, e a saída vem em hexadecimal (chave pública e chave secreta)

O erro comum deste passo: não salvar a chave secreta NA HORA

Ela não é armazenada e não pode ser recuperada, então se tu fechar o terminal sem copiar, é gerar tudo de novo

2. Adicione o agente ao canal com o buzz channels add-member, informando o canal, a chave pública do agente e o papel bot

buzz channels add-member --channel CHANNEL_UUID --pubkey AGENT_PUBLIC_KEY --role bot

Esse comando roda com uma credencial de relay-owner, entregue pelas variáveis BUZZ_RELAY_URL e BUZZ_PRIVATE_KEY somente nesse momento

O erro comum deste passo: deixar a credencial de relay-owner morando no arquivo de ambiente do agente

Tome cuidado! A graça do modelo é o agente ter poder só de membro do canal, e uma credencial de dono do relay largada ali joga fora justamente esse recorte

3. Ligue o agente ao Buzz pelo buzz-acp, que é o harness ACP responsável por conectar agentes de IA à plataforma

Ele conecta ao relay por WebSocket com autenticação NIP-42, descobre canais via API REST, escuta as menções com @ e enfileira os eventos de menção por canal

O erro comum deste passo: assumir que toda resposta do agente chega no canal

Existe issue aberta no repositório oficial (a #2698) relatando que a entrega de resposta no buzz-acp é implícita, e que respostas de agentes que respondem no texto da sessão podem ser descartadas em silêncio

Triar um bug sem entregar o projeto inteiro ao agente:

Agora junta as peças

Se a participação no canal é a unidade de permissão, o canal vira o recorte do que o agente enxerga e do que ele pode escrever

Coloca o agente no canal do bug e só nele

Fora dali, ele nem discute: a requisição é rejeitada pelo relay

O fluxo dentro do canal fica assim: alguém menciona o agente com @, o buzz-acp captura a menção e dispara o prompt, e o agente responde usando o Buzz CLI

O buzz-cli é uma CLI pensada pra agente, com JSON in e JSON out, que espelha e estende a superfície MCP e permite operar a plataforma inteira sem interface gráfica

É o tipo de detalhe que separa "bot que manda mensagem" de "participante que trabalha", né?

E não fica preso a um agente só: o buzz-acp suporta qualquer agente que fale ACP por stdio, incluindo goose, codex (via codex-acp) e Claude Code (via claude-agent-acp)

Essa ideia de recortar contexto por canal é velha conhecida de quem cuida de agentes multicanal no dia a dia, a diferença aqui é que o recorte não é uma convenção do teu fluxo, é o próprio mecanismo de acesso da plataforma

O que a trilha de auditoria realmente prova:

Aqui eu preciso ser chato, porque "auditoria" virou palavra de marketing e no Buzz ela tem uma definição bem concreta

Todo evento é criptograficamente assinado e carrega:

• id, o sha256 dos bytes canônicos
• pubkey, a chave pública secp256k1
• kind, um inteiro
• tags
• content
• sig, a assinatura Schnorr

Esses eventos são gravados num log de auditoria à prova de adulteração (o crate buzz-audit), com cada entrada encadeada à anterior por hash SHA-256

E aqui vem a honestidade que eu gostei de ver na própria documentação: como a cadeia é sem chave, ela é tamper-evident e NÃO tamper-resistant

Traduzindo: ela serve pra detectar corrupção, não pra impedir que alguém mexa

Já é muito mais do que log de aplicação comum, mas não é selo mágico

E o cenário que todo mundo pensa: e se a chave do agente vazar?

Dá pra revogar o agente sem trocar a identidade humana por trás dele

Além disso, remover o dono faz o agente não conseguir mais reconectar

Pra mim esse é o argumento mais forte do modelo todo: o estrago fica no escopo do agente, não na conta da pessoa

O que já funciona e o que ainda não está pronto:

O Buzz é bem completão de componentes pra uma plataforma anunciada em julho de 2026

Por dentro ele é dividido em:

• buzz-core: tipos, verificação e filtros
• buzz-db: Postgres pra eventos, canais, tokens, workflows e auditoria
• buzz-auth: NIP-42, NIP-98, tokens de API, escopos e rate limiting
• buzz-pubsub: Redis, presença e indicador de digitação
• buzz-search: busca full text no Postgres
• buzz-audit: o log encadeado
• buzz-relay: o servidor principal

Agora a parte que ninguém coloca no anúncio

O gate de aprovação de workflow ainda está incompleto: schema, endpoints REST, ferramenta MCP e interface existem, mas o executor ainda não persiste o token de aprovação nem suspende a execução

Resultado prático: um run que chega no passo request_approval é marcado como Failed (é a #2878, identificada como WF-08)

Somando com a #2698, que já citei lá em cima, o recado é claro: a camada de identidade e auditoria está de pé, a camada de "humano aprova antes do agente seguir" ainda não está

Se o teu plano era justamente colocar um humano no meio do caminho como trava, segura a onda um pouco…

Por onde começar:

Tem dois caminhos, e os dois são verificáveis hoje

O primeiro é subir a tua própria instância na tua infraestrutura, e a Block publicou um guia oficial pra isso, o Run your own Buzz relay, no blog de engenharia deles

O segundo é usar a hospedagem da própria Block em buzz.xyz, criando conta e comunidade, que está gratuita em early beta

Se tu só quer bisbilhotar o código antes de decidir qualquer coisa, o repositório é o github.com/block/buzz, Apache-2.0, tudo aberto

Minha sugestão de primeiro teste: um canal, um bug, um agente com keypair próprio, e olhar a trilha depois pra ver quem fez o quê

É o experimento mais barato pra sentir se esse modelo de identidade resolve a tua dor ou se é só arquitetura bonita 😀

até o próximo post!