Block Buzz: o espaço de trabalho de agentes IA onde agentes são colegas, não bots
A maioria das configurações de "IA no seu chat" funciona do mesmo jeito: você acopla um bot ao Slack ou Discord, dá a ele um comando de barra, e ele responde quando convocado. O bot vive fora do time. Ele tem uma identidade separada, uma trilha de auditoria separada e um teto rígido sobre o que pode tocar. A Block olhou para esse padrão e decidiu que o agente deveria simplesmente ser um membro da sala.
Essa ideia é o Buzz, um espaço de trabalho de código aberto da Block, Inc. que já atraiu cerca de 18.000 estrelas no GitHub. No Buzz, humanos e agentes IA compartilham os mesmos canais, assinam suas ações com o mesmo tipo de chave criptográfica e acabam no mesmo log pesquisável. Ele é escrito em Rust e licenciado sob Apache 2.0. Passei um tempo lendo os documentos de arquitetura do repositório para que você não precise, e as escolhas de design são mais interessantes do que o marketing sugere.
O que é o Block Buzz?
O Buzz é um espaço de trabalho auto-hospedável da Block, Inc. onde humanos e agentes IA compartilham os mesmos canais. Ele roda sobre um relay Nostr, de modo que cada mensagem, reação, patch de código, aprovação e etapa de workflow é um evento assinado em um único log pesquisável e à prova de violação. Ele é de código aberto sob Apache 2.0, construído em Rust, e você mesmo opera o relay.
Principais pontos:
- Agentes são membros de primeira classe com suas próprias chaves e trilha de auditoria, não bots acoplados de lado.
- Tudo (chat, patches, CI, aprovações) é um evento Nostr assinado em um único log pesquisável.
- Agentes se conectam via ACP e MCP, então Goose, Codex e Claude Code funcionam de cara.
- Auto-hospedado e de código aberto (Apache 2.0), com uma lista honesta e pública do que ainda não está pronto.
A frase em que o projeto se apoia é "a hive mind communication platform". Isso soa grandioso, mas a realidade do dia a dia é mais simples: parece um espaço de trabalho de equipe. Canais, threads, mensagens diretas, um canvas, huddles de voz, busca. A virada é o que está por baixo. Cada ação é um evento Nostr assinado, e o autor desse evento pode ser uma pessoa ou um processo. Mesma forma, mesmo modelo de identidade, mesma trilha de auditoria em ambos os casos.
Se você tem comparado frameworks de agentes como LangGraph, CrewAI e o OpenAI Agents SDK, o Buzz é uma camada inteiramente diferente. Aqueles são bibliotecas que você incorpora no código para orquestrar o raciocínio de um agente. O Buzz é a sala onde o agente e seu time conversam, passam trabalho adiante e deixam um registro. Eles são complementares, não concorrentes.
Por que "agentes como membros" muda o modelo
O modelo de bot tem um problema estrutural: o agente é um convidado. Você concede flags de permissão, ele opera por uma API estreita, e quando algo dá errado você está reconciliando dois históricos separados — o chat do time e os logs do bot.
O Buzz inverte isso. Um agente recebe seu próprio par de chaves, suas próprias associações a canais e sua própria trilha de auditoria. Você adiciona um agente a um canal do mesmo jeito que adiciona uma pessoa. O projeto descreve a definição de escopo como "by identity, not by permission flags", que é o mesmo jeito que você definiria o escopo de um colega humano. Você confia neles em algumas salas e não em outras.
Uma vez que um agente é membro, ele recebe as mesmas possibilidades que todos os outros. Ele pode abrir repositórios, enviar patches, revisar código, executar workflows, editar canvases, orquestrar outros agentes, criar canais e entrar em huddles de voz. O README percorre três cenários que tornam isso concreto:
- Memória de incidentes. São 2h da manhã, você pergunta "já vimos esse erro antes?", e um agente observando o canal puxa seis meses de histórico, publica as threads e as causas raiz, e se oferece para chamar quem enviou o último fix. A troca inteira fica no canal como evidência.
- Branch como sala. Você abre um branch de funcionalidade e um canal aparece. Patches chegam como eventos, a CI publica resultados, um agente faz uma primeira revisão, e a decisão de merge vive na mesma sala que as evidências que a justificaram.
- Um release que se escreve sozinho. Um workflow dispara em uma tag, um agente redige notas de release a partir dos PRs mesclados, publica para revisão humana, recebe uma reação de joinha, e envia. Cada etapa assinada, cada etapa pesquisável.
O fio comum é que a conversa, o código e a decisão vivem todos em um lugar, em vez de sete abas fingindo que se conhecem.
Como os agentes realmente se conectam: ACP e MCP
É aqui que a engenharia fica limpa. O Buzz entrega dois binários pequenos para agentes, e eles deliberadamente não sabem um do outro.
buzz-agent é um agente ACP. Ele fala o Agent Client Protocol sobre stdio, chama um LLM, e usa ferramentas MCP. Ele executa até oito sessões simultâneas, cada uma com seus próprios servidores MCP, histórico e contexto. Quando o contexto de uma sessão enche, ela resume seu próprio histórico e continua. Ele funciona com Zed, JetBrains ou qualquer outra coisa que fale ACP.
buzz-dev-mcp é um servidor MCP. Ele dá a qualquer agente um shell e um editor de arquivos. Processos são efêmeros com kill de grupo de processos em cada caminho de saída, a saída é limitada, e as edições de arquivo se resolvem contra o diretório de trabalho. Se você já construiu com o Model Context Protocol antes, isso vai parecer familiar: é o padrão "dar mãos a um agente", endurecido.
A nota de design no repositório diz sem rodeios: "two binaries, two protocols, no coupling between them." O agente não sabe com qual servidor MCP fala, e o servidor MCP não sabe qual agente o chama. Eles se compõem por protocolos, não por imports. O ganho prático é que você pode rodar dez agentes atrás do Buzz com diferentes configurações de MCP, ou trocar seu provedor de LLM com uma variável de ambiente.
Como o buzz-acp faz a ponte das @mentions do relay para subprocessos de agentes, você pode apontá-lo para Goose, Codex ou Claude Code. Se você já roda agentes de codificação em segundo plano, o Buzz dá a eles uma sala compartilhada para operar, em vez de um loop headless silencioso. E se você quer trazer suas próprias ferramentas, construir um servidor MCP é o caminho suportado, com muitos servidores MCP prontos para começar.
Sob o capô: a arquitetura
O Buzz é um monorepo Rust, e o fato mais importante é este: o relay é a única fonte de verdade. Não há fofoca peer-to-peer nem replicação. Clientes se conectam a um relay por WebSocket, e o relay cuida da autenticação, verifica assinaturas, persiste eventos, distribui para assinantes, indexa para busca, e dispara automações.
Tudo é um evento Nostr NIP-01. Cada evento tem seis campos: um id (SHA-256 do evento serializado), um pubkey, um inteiro kind, tags, conteúdo, e uma assinatura Schnorr. O inteiro kind é o único chaveador de despacho. Quer um recurso novo? Defina um novo número de kind. Clientes existentes não veem nada e não quebram nada. A base de código define 81 kinds, com kinds personalizados do Buzz vivendo na faixa 40000-49999.
A pilha de suporte é deliberadamente entediante, no melhor sentido:
| Crate | Papel |
|---|---|
buzz-core | Tipos sem I/O, verificação Schnorr, correspondência de filtros, registro de kinds |
buzz-relay | O servidor Axum que amarra todos os subsistemas |
buzz-db | Armazém de eventos Postgres, canais, workflows, particionamento mensal |
buzz-auth | Autenticação Schnorr NIP-42 e NIP-98, escopos |
buzz-pubsub | Distribuição pub/sub Redis, presença, indicadores de digitação |
buzz-search | Busca full-text Postgres sobre uma coluna tsvector gerada |
buzz-audit | Cadeia de hash, log de auditoria à prova de violação |
buzz-workflow | Motor de automação YAML-como-código |
buzz-cli | CLI agent-first, JSON de entrada / JSON de saída |
buzz-acp | Faz a ponte das @mentions do relay para agentes IA via ACP |
O Postgres guarda os eventos e executa a busca full-text. O Redis cuida da distribuição pub/sub, presença e digitação. Armazenamento de objetos compatível com S3 (MinIO localmente) guarda a mídia via protocolo Blossom.
O modelo de segurança é onde parei de folhear. Cada evento tem sua assinatura Schnorr e ID SHA-256 verificados antes do armazenamento. A autenticação NIP-42 usa uma tolerância de timestamp de ±60 segundos para bloquear ataques de replay, e eventos de autenticação nunca são armazenados ou auditados. O log de auditoria é uma cadeia de hash genuína: o SHA-256 de cada entrada cobre cada campo, incluindo o hash anterior, de modo que violar uma entrada quebra todas as entradas depois dela. Webhooks de saída recebem proteção SSRF que verifica faixas de IP privadas. E a associação ao canal é o único portão de acesso, aplicado em cada operação, com o handler de assinatura verificando o acesso antes de registrar uma assinatura, de modo que não há janela de corrida para vazamentos de canais privados.
Se você está avaliando como implantar IA agêntica em infraestrutura que controla, esta é a parte que vale a pena ler duas vezes.
O que funciona hoje (e o que não funciona)
O projeto é incomumente honesto sobre seu próprio status, e acho que essa honestidade é o sinal mais forte de uma base de código séria. Aqui está o estado atual direto do repositório:
| Status | Capacidade |
|---|---|
| ✅ Funciona hoje | Relay, canais, threads, mensagens diretas, canvases, mídia, busca, log de auditoria, app desktop (Tauri + React), buzz-cli + harness ACP, workflows YAML, eventos Git (NIP-34), backend de hospedagem git |
| 🚧 Em andamento | Clientes móveis (iOS + Android, Flutter), portões de aprovação de workflow, eventos de ciclo de vida de huddle |
| 💭 Código pendente | Reputação web-of-trust entre relays, notificações push |
Agora a parte que a maioria dos posts de produto pula. O documento de arquitetura lista lacunas verificadas, não aspirações:
- Nenhum rate limiting é aplicado ainda. O trait
RateLimiterexiste e quatro níveis foram projetados (human, agent-standard, agent-elevated, agent-platform), mas a única implementação é um stub de teste. - Portões de aprovação não estão ligados de ponta a ponta. O executor pode suspender uma execução, mas um workflow que atinge um portão de aprovação é atualmente marcado como falho.
- Algumas ações de workflow são stubs.
send_dmeset_channel_topicretornam "not implemented", então uma execução que chega a uma falha. - Gravação de huddle e publicação por faixa não estão construídas. Salas de voz e ciclo de vida de entrar/sair funcionam; gravação tem kinds de evento reservados mas nenhum produtor.
- Sem cache de consultas sqlx offline. As consultas rodam em tempo de execução em vez de serem validadas em tempo de compilação.
Nada disso é desqualificante para uma ferramenta auto-hospedada que você está avaliando, mas diz exatamente onde estão as bordas. Se você precisa avaliar agentes em produção com garantias rígidas, trate as colunas 💭 e 🚧 como avisos estruturais.
Começando com o Buzz
Há três caminhos, dependendo de quem você é.
Só quer experimentar? Pegue um build empacotado do release mais recente: macOS (.dmg), Linux (.AppImage ou .deb), ou Windows (.exe). Por padrão ele se conecta a ws://localhost:3000, então você ainda vai querer um relay rodando.
Quer compilar do código-fonte? Você precisa de Docker e Hermit ou Rust 1.88+, Node 24+, pnpm 10+, e just. Então:
git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit
just setup && just build
# every day:
. ./bin/activate-hermit
just dev # starts the relay + desktop app togetherO relay aterrissa em ws://localhost:3000 e o app desktop aparece. Para uma implantação VPS de nó único em vez da pilha de desenvolvimento local, há um bundle Compose de produção sob deploy/compose/ com Postgres, Redis, MinIO, e Caddy opcional para TLS.
Trazendo um agente? Defina BUZZ_PRIVATE_KEY e use o buzz-cli, que é JSON de entrada e JSON de saída, projetado especificamente para chamadas de ferramentas LLM. Essa é a costura onde seus workflows de agentes se conectam.
Quem deve rodar o Buzz?
O Buzz é para times que querem um substrato único em vez de uma pilha de código de cola. Se sua configuração atual é chat mais uma forge mais bots mais dashboards de CI mais ferramentas de release mais um índice de busca, e você está cansado de eles não se conhecerem, esta é a aposta que o Buzz faz: uma comunidade, um modelo de identidade, um log de eventos.
Ele é uma boa escolha para:
- Auto-hospedadores que querem seu tráfego de agentes em infraestrutura própria, com uma trilha de auditoria que podem verificar.
- Engenheiros de plataforma avaliando workflows agent-first onde agentes triam bugs, executam revisões e redigem releases como membros, em vez de scripts.
- Avaliadores de código aberto que querem ler tudo em uma tarde. A superfície de agentes são dois crates sem acoplamento, deliberadamente pequenos o bastante para auditar.
Ainda não é para quem quer um SaaS pronto e completo para entregar amanhã a um time não técnico. Os portões de aprovação, o rate limiting e os clientes móveis ainda estão chegando. O Buzz diz isso abertamente, o que é exatamente a razão pela qual eu confiaria a ele um piloto cuidadoso.
O enquadramento a que volto sempre está no README: "Agents are part of the room, not haunted cron jobs." Se você já depurou um bot às 2h da manhã sem ideia do que ele fez ou por quê, já sabe por que isso importa.
FAQ
O Buzz é gratuito e de código aberto?
Sim. O Buzz é de código aberto sob a licença Apache 2.0 e construído pela Block, Inc. Você auto-hospeda o relay, então não há taxa por assento pelo software. Seus custos são sua própria infraestrutura: um servidor para o relay, Postgres, Redis e armazenamento de objetos. O código-fonte, os issues e o roadmap são todos públicos no GitHub em block/buzz.
Como o Buzz difere do Slack com bots?
No Slack, um agente é um bot de segunda classe com identidade e trilha de auditoria separadas, com escopo por flags de permissão. No Buzz, um agente é um membro de primeira classe com seu próprio par de chaves, associações a canais e as mesmas possibilidades que um humano: abrir repositórios, enviar patches, executar workflows, participar de huddles. Tudo aterrissa em um único log de eventos assinado e pesquisável.
O que são ACP e MCP?
ACP é o Agent Client Protocol, a interface stdio que o buzz-agent usa para falar com um cliente LLM como o Zed. MCP é o Model Context Protocol, a interface que o buzz-dev-mcp usa para dar a um agente um shell e um editor de arquivos. Os dois binários não sabem um do outro; eles se compõem por protocolos, então você pode misturar agentes e servidores de ferramentas livremente.
O Buzz usa blockchain?
Não, e o README é direto sobre isso: "Not blockchain. Signed events are useful without making everyone buy a commemorative coin." O Buzz usa as assinaturas criptográficas do Nostr e um log de auditoria de cadeia de hash para prova de violação, mas não há token, nem cadeia, nem mecanismo de consenso. Você obtém histórico verificável sem o overhead.
Posso usar meus próprios agentes IA, como Goose, Codex ou Claude Code?
Sim. O harness buzz-acp gera subprocessos de agentes IA e faz a ponte das @mentions do relay para eles via ACP. Ele suporta Goose, Codex e Claude Code de cara, roda um pool de um a 32 processos de agentes, e reinicia um agente se ele travar. Para ferramentas personalizadas, você conecta seu próprio servidor MCP.
O Buzz está pronto para produção?
Em parte. O relay, os canais, a busca, o log de auditoria, o app desktop e o CLI de agentes funcionam hoje. Mas o rate limiting não é aplicado, os portões de aprovação não estão ligados de ponta a ponta, e os clientes móveis ainda estão em andamento. Para um piloto auto-hospedado com um time que tolera bordas ásperas, está pronto para experimentar. Para uma implantação crítica em conformidade, espere os itens 🚧 chegarem.
Sobre o autor
Mert Batur é cofundador da Techsy.io, onde o time entrega agentes IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Ele escreve sobre a pilha de ferramentas LLM que o time da Techsy realmente usa em produção. Conecte-se com ele no LinkedIn.