Workflows em YAML no Buzz: quais gatilhos existem e para que servem?

Automação que mora em arquivo é automação que dá pra ler, revisar e versionar junto do resto do projeto

E é exatamente essa a aposta do Buzz: o workflow não é um fluxograma arrastado na tela, é um YAML com escopo de canal

O Buzz é uma plataforma de colaboração open source criada pela Block, empresa de Jack Dorsey, onde humanos e agentes de IA trabalham no mesmo espaço

Ele foi anunciado em 21 de julho de 2026, ainda em beta inicial, com licença Apache-2.0 e código aberto em github.com/block/buzz

Neste post o foco é um pedaço específico: quais gatilhos existem nos workflows do Buzz e pra que cada um serve na prática

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

O que é um workflow em YAML no Buzz e onde ele vive

Um workflow no Buzz é um arquivo YAML com escopo de canal

Ou seja: ele não paira sobre o espaço todo, ele pertence a um canal e reage ao que acontece ali dentro

A estrutura é bem direta: um gatilho define quando aquilo dispara, e uma lista LINEAR de passos define o que acontece depois

Nada de ramificação maluca, é de cima pra baixo

E os passos não são livres, saem de um conjunto fixo de ações:

• send_message
• send_dm
• set_channel_topic
• add_reaction
• call_webhook
• request_approval
• delay

Se você conhece automação de repositório, é um raciocínio parecido: arquivo declarado, evento que dispara, passos que rodam

E quem executa isso?

A automação YAML é provida pelo crate `buzz-workflow`

Ele usa o evalexpr pra avaliar as condições dos filtros, aquelas expressõezinhas que decidem se o gatilho realmente vale pra aquele evento ou não

Por que cada passo sai assinado:

Esse detalhe é dos mais massa do projeto

O Buzz roda sobre o protocolo Nostr e cada participante, humano ou agente, tem o próprio par de chaves criptográficas

Cada um assina os eventos que produz

Então quando um agente age dentro de um canal, aquilo carrega identidade, não é um robô anônimo postando em nome de ninguém

Os cinco gatilhos lado a lado: o que dispara cada um

Muita gente cita quatro gatilhos (mensagem, reação, agendamento e webhook), mas são CINCO no total

Segue a visão completa:

Repare no padrão: os gatilhos de conteúdo (mensagem e diff) filtram por expressão, o de reação filtra por emoji, e os outros dois vêm de fora do canal (relógio e requisição HTTP)

Para que serve cada gatilho na prática

Gatilho sem caso de uso é só nome de campo, né? Bora aterrissar cada um

message_posted: palavra-chave vira comando

Esse é o mais óbvio e o mais usado

O time conversa normal no canal e uma expressão específica dispara a automação

O filtro str_contains(trigger_text, 'ship it') é o exemplo clássico: a automação só acorda quando aquela frase aparece, e não a cada mensagem solta do canal

Sem filtro, todo mundo dando bom dia vira execução de workflow 😛

reaction_added: o dedão como confirmação

A reação é o jeito mais barato de um humano dizer "ok, pode seguir" sem escrever nada

Dá pra filtrar por emoji específico, então o 👍 tem um efeito e o 🚀 tem outro

E se você omitir o filtro, qualquer reação casa

Tome cuidado com isso: sem filtro, um emoji de risada em cima da mensagem errada também dispara o fluxo

diff_posted: código chegando no canal

Esse é o gatilho que amarra conversa com mudança de código

Quando um diff é postado no canal, o workflow acorda, e o filtro em evalexpr permite reagir só a um recorte do que chegou

É o caminho natural pra rotinas que acompanham o que o time (ou o agente) está mudando

schedule: rotina no relógio

Aqui não tem evento nenhum no canal, é o tempo passando

Dá pra usar expressão cron, quando você quer precisão de horário e dia, ou um intervalo simples tipo 1h e 30m, quando você só quer que aquilo rode de tempos em tempos

Resumo do canal, lembrete recorrente, checagem periódica: tudo mora aqui

webhook: o mundo de fora batendo na porta

O Buzz gera uma URL de webhook e um secret no momento em que o workflow é criado

Quando uma requisição autenticada chega nessa URL, o workflow roda

É a ponte com o resto da sua stack: qualquer sistema que saiba fazer um POST consegue acender uma automação dentro do canal

O exemplo que a Block usa pra explicar tudo isso

A própria Block descreveu o cenário que amarra a ideia toda, no anúncio oficial do Buzz

Depois de uma tag de release, um agente lê os PRs mergeados dos canais do projeto

Ele rascunha as release notes

Posta no canal pra revisão humana

Aguarda o 👍

E só ENTÃO publica, com cada passo assinado

Olha como o desenho fecha: um evento inicia, o agente produz, a reação humana libera, e a assinatura deixa rastro de quem fez o quê

O que já funciona e o que ainda está sendo ligado

Agora a parte honesta, porque o Buzz está em beta e isso aparece

O README lista mensagem, reação, agendamento e webhook como funcionando

Mas classifica os approval gates como "being wired up": a infraestrutura existe, a integração ainda não foi concluída

Essa correção entrou na tabela de status do README em 03/08/2026

E olha um detalhe que é fácil passar batido: o diff_posted NÃO aparece nessa lista de status

Ele está documentado como gatilho, isso é certo, mas o README não carimba ele como funcionando junto dos outros quatro, e o motivo dessa ausência não está declarado ali

Ou seja: se o seu fluxo depende do diff_posted, testa ele antes de apostar tudo

As pedras conhecidas hoje:

• Issue #2878: a sintaxe from: documentada pro request_approval é rejeitada no momento da aprovação, e a única sintaxe que funciona acaba aceitando qualquer chave da comunidade
• Issue #2981: workflow não escopa pra todos os canais, então capturar reações exige uma cópia do workflow POR canal
• Não existe ação nativa que invoque um agente com um prompt: invoke_agent é uma proposta em issue aberta (#2702), o conjunto de ações atual não inclui isso

E aí vem a pergunta que interessa: dá pra montar o fluxo de release notes hoje?

A parte de disparo está de pé nos quatro gatilhos que o README dá como funcionando, e o motor de condição também

O pedaço frágil é justamente o portão humano no fim: com os approval gates ainda sendo ligados e o bug do from: em aberto, o "só publica depois do aprovado" é o ponto que merece o seu ceticismo antes de virar produção

Quem quiser brincar agora, brinque sabendo disso

Vídeo: como organizar workflows

Pra começar do zero com o assunto e pegar o raciocínio de organizar automações antes de sair declarando arquivo, este vídeo do canal serve bem de porta de entrada:

Conclusão

A leitura dos workflows do Buzz cabe em uma frase: o gatilho define QUANDO, a lista de passos define O QUÊ, e cada passo sai assinado por causa do Nostr

São cinco gatilhos (message_posted, reaction_added, diff_posted, schedule e webhook), um conjunto fixo de ações e o evalexpr decidindo os filtros

A aprovação humana é o pedaço ainda em construção, e vale acompanhar

Próximo passo concreto? Rodar sua própria instância e olhar de perto

A versão hospedada em buzz.xyz e o self-hosting são gratuitos, sem nenhum plano pago, limite de uso ou preço enterprise publicado até 03/08/2026

Pra deploy próprio, o README passou a apontar um bundle oficial de Docker Compose em 01/08/2026, e a Block publicou um deploy one-click no Railway em 02/08/2026

E se você curte mexer via terminal, dá uma olhada na `buzz-cli`, em `crates/buzz-cli`: é a CLI agent-first do relay, com JSON de entrada e JSON de saída, pensada pra chamada de ferramenta de LLM

até o próximo post! 😀