“Já vimos esse erro antes?”: como um agente busca o histórico no Buzz

Fala aí, beleza? Imagina a cena no canal do time: cai um stack trace feio e alguém solta a pergunta mais velha da engenharia, "já vimos esse erro antes?"

Aí um agente que acompanha aquele canal varre seis meses de histórico e volta com as threads reais, as causas-raiz e as correções, se oferecendo pra chamar quem mandou a última

Esse caso não é hipótese de marketing, tá no próprio README do projeto

E ele só existe por um motivo estrutural: no Buzz, mensagem, reação, patch de git, resultado de CI, passo de workflow e aprovação de review são eventos assinados no MESMO log, com o mesmo modelo de identidade, seja o autor uma pessoa ou um processo

O que é o Buzz e por que o histórico dele é pesquisável

O Buzz é um workspace open source da Block (a empresa do Jack Dorsey) onde pessoas e agentes de IA ficam nos mesmos canais

Formação Recomendada

Formação Claude Code

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

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Foi anunciado em 21 de julho de 2026, sob licença Apache 2.0, e o repositório oficial fica em github.com/block/buzz, descrito como "A hive mind communication platform"

A tração veio rápido: eram cerca de 6,9 mil estrelas nos três primeiros dias e cerca de 21,9 mil em 4 de agosto de 2026 😀

Mas o número não é o ponto aqui, o ponto é a arquitetura

Na maioria das ferramentas, o chat é um lugar e o CI, o patch e a aprovação são outros três

O histórico vira aquela lembrança vaga de "acho que o fulano resolveu isso em algum canal"

No Buzz, tudo isso cai no mesmo log assinado, com a mesma trilha de auditoria

É essa decisão que transforma "histórico de chat" em base pesquisável, e é ela que deixa um agente responder com evidência em vez de achismo

O que o agente precisa antes de buscar qualquer coisa

Antes do comando, o modelo de identidade

Cada agente no Buzz recebe o próprio par de chaves Nostr, as próprias participações em canais e a própria trilha de auditoria

O escopo é por IDENTIDADE, não por flag de permissão numa tela de configuração

Na prática isso significa uma coisa simples e importante: o agente busca todo o histórico dos canais a que ele tem acesso, do mesmo jeito que uma pessoa buscaria

Canal em que ele não é membro não entra na conta

A superfície que ele usa pra trabalhar vem em crates separados:

• buzz-cli: a CLI feita pra agente, JSON de entrada e JSON de saída, espelhando e estendendo a superfície MCP
• buzz-acp: o harness ACP (Agent Client Protocol) por stdio, que aceita goose, Codex via codex-acp e Claude Code via claude-agent-acp
• buzz-agent, buzz-dev-mcp (ferramentas de shell e edição de arquivo), buzz-workflow (automação em YAML) e buzz-persona

Repara que a CLI não foi desenhada pra ser bonita no terminal, ela foi desenhada pra ser consumida por um programa

JSON entrando, JSON saindo, é isso que deixa o agente usar a ferramenta direto, sem ninguém traduzindo no meio

Como a busca acontece por dentro, passo a passo

Vamos seguir o caminho da pergunta até a resposta

1. A pergunta cai no canal e o agente membro lê

Não tem gatilho mágico nem prompt secreto, ele está no canal como qualquer outro participante, com chave própria

2. A query é escopada por h tag

Canais no Buzz usam h tags (a tag de grupo do NIP-29), não e tags

Filtros e queries que operam dentro de um canal precisam ter escopo por h tag

O erro comum deste passo: escopar por e tag por hábito de outros clientes Nostr, e aí a busca simplesmente não enxerga o canal certo

3. Os filtros de busca NIP-50 são roteados pro buzz-search

Isso acontece automaticamente, e o buzz-search é full-text no Postgres

Então calibra a expectativa: é busca textual, com o Postgres fazendo o trabalho pesado

4. Pela CLI, a busca vira um comando com filtros

buzz messages search --query "architecture"

Dá pra fatiar por autor e por janela de tempo:

buzz messages search --query "timeout" --author npub1exemplo --since 1750000000

O --author aceita pubkey, npub ou nome, e o --since espera timestamp unix

O erro comum deste passo: mandar data legível no --since e ficar quebrando a cabeça com resultado vazio

5. A leitura volta como JSON puro

As leituras retornam arrays JSON sem assinatura em stdout, e os erros saem como JSON em stderr

Daí o agente resume as threads pro humano

O erro comum deste passo: esperar uma resposta "conversada" da CLI

Ela é JSON in, JSON out, e quem escreve a frase final é o agente, não a ferramenta

Além do incidente: onde a busca no histórico vira trabalho

O caso do erro repetido é o mais óbvio, mas ele é só a porta de entrada

Memória de incidente: a pergunta do começo do post, com o agente devolvendo thread, causa-raiz e correção, e sugerindo chamar quem enviou a última

Canal por branch: patches chegam como eventos NIP-34, e uma branch pode virar canal

Aí patch, CI, review do agente e a decisão de merge ficam no mesmo lugar que a evidência

Buscar "por que mudamos isso" devolve a discussão junto do diff, não um link solto pra um PR fechado lá atrás

Recuperar decisão de arquitetura: --author mais --since é o combo pra achar o que uma pessoa específica defendeu num período específico

Auditoria de quem aprovou o quê: aprovações de review são eventos no mesmo log, então elas são pesquisáveis igual a qualquer mensagem

E tem a automação: o buzz-workflow é YAML, não canvas visual

Se você vem de montar fluxos de automação no n8n, a troca é arrastar nó por arquivo versionado que vive junto do resto do histórico

O limite, pra ser honesto: o agente devolve as threads REAIS que existem no log

Se a discussão nunca aconteceu ali, não tem mágica que faça aparecer

A trilha de auditoria: o que ela garante (e o que não garante)

Aqui mora a parte que quase ninguém conta direito

O crate buzz-audit encadeia cada entrada do log com SHA-256

Cada entrada guarda o prev_hash da anterior, a entrada gênese usa o GENESIS_HASH (64 zeros) e a função verify_chain() percorre o log recalculando os hashes

Em modo multi-comunidade, as cadeias e os heads são por comunidade, então a verificação legível pelo tenant percorre a cadeia de UMA comunidade só

Se você já mexeu com git, a analogia é confortável: cada coisa aponta pro hash da anterior, e mexer no meio quebra o resto

Mas se liga no veredito honesto, que a própria documentação de arquitetura assume: por ser encadeamento sem chave, o log é tamper-evident, não tamper-resistant

Ou seja, ele detecta corrupção acidental e a edição de uma linha solta

Só que quem tem acesso de escrita no banco pode editar e recalcular a cadeia inteira depois

É prova contra descuido e contra edição preguiçosa, não é prova contra alguém com as chaves do cofre na mão

Tome cuidado com quem vende isso como "log imutável", porque não é o que está escrito lá

Vale usar o Buzz hoje para isso?

Depende do que você espera encontrar

O projeto está em estágio inicial, alfa/beta, e a expectativa declarada é justamente essa: você vai achar bug e coisa que não funciona na primeira tentativa

E tem furo documentado no caminho de aprovação:

O detalhe do WF-08: a ação request_approval devolve StepResult::Suspended com um token UUID, mas o executor ainda não persiste o token nem retoma a execução

Resultado: a run que bate nesse passo é marcada como Failed

E tem a issue #2878 aberta no repositório apontando que a sintaxe from: documentada pro request_approval é rejeitada na hora da aprovação, sendo que a sintaxe que funciona aceita qualquer chave da comunidade

Ou seja: pra fluxo de aprovação automatizada, ainda não é hora

Pra memória de incidente e busca de histórico, o que sustenta o caso de uso já está de pé

E dá pra experimentar sem custo: tem a hospedagem da própria Block em buzz.xyz, grátis em beta inicial, ou self-host gratuito na sua infra

Conclusão

A ideia central é essa, e ela é simples de resumir: histórico deixa de ser arquivo morto e vira memória consultável quando conversa, patch, CI, workflow e aprovação moram no mesmo log assinado

O agente não "lembra" de nada, ele busca, e busca só onde tem identidade e membership

Se quiser ver de perto, o caminho curto é a hospedagem da Block em buzz.xyz, com cliente desktop em Tauri e instaladores pra macOS, Linux e Windows (a versão mais recente é a Buzz Desktop v0.5.4, de 3 de agosto de 2026)

O caminho do self-host a partir do código pede Docker mais Rust 1.88+, Node 24+ e pnpm 10+ (ou o toolchain Hermit que já vem no repo):

git clone https://github.com/block/buzz
just setup && just build && just dev

Minha sugestão: não tenta migrar o time inteiro de cara

Sobe um canal só, joga o histórico de um serviço nele e testa exatamente o caso do incidente, aquele "já vimos esse erro antes?"

Se o agente voltar com thread de verdade, você já sabe o que fazer em seguida… 🙂

até o próximo post!