Quando os agentes se tornam colegas: a ideia por trás do Buzz

Já escrevi sobre o Buzz, na altura com um foco claro no Shared Compute e na operação partilhada de modelos. Para mim, essa era inicialmente a parte mais interessante e invulgar do projeto. Mas quanto mais tempo passo com o Buzz, mais interessante se torna o próprio espaço de trabalho. Por isso testei entretanto o Buzz numa pequena configuração.

Isto também tem a ver com um problema que sinto cada vez mais claramente nos últimos meses. O meu trabalho com IA tornou-se não só mais rápido, mas também mais confuso. O Codex trabalha num repositório, o Claude Code verifica uma segunda ideia, outro agente recolhe informações, e algures no meio disto tudo correm o terminal, o browser, o e-mail e vários chats. Cada agente pode ser útil por si só. O problema surge nas transições. É preciso copiar contexto, repetir decisões e juntar manualmente os resultados.

É exatamente aí que entra o Buzz. O projeto de código aberto vem da Block, a empresa liderada pelo cofundador do Twitter, Jack Dorsey, por trás da Square. Não quer construir mais um assistente de IA. O Buzz cria um espaço de trabalho comum, onde pessoas e agentes usam os mesmos canais, threads, projetos e protocolos. Um agente Codex pode criar um plano, o Claude Code pode criticá-lo, uma pessoa pode tomar a decisão e o agente seguinte pode transformá-la numa alteração no repositório. Toda a cadeia permanece visível no mesmo espaço.

O termo rápido “assassino do Slack” fica curto para mim. O Buzz mostra uma possível forma de trabalho para equipas com muitos agentes. Ao mesmo tempo, ainda é jovem, exigente em recursos e mais complexo em termos de segurança do que a interface amigável faz supor. É precisamente essa mistura de grande ideia e estado de desenvolvimento inicial que torna um olhar mais atento interessante.

O verdadeiro problema não é o modelo

A maioria das ferramentas de IA surgiu como uma relação entre uma pessoa e um agente. Abro o Codex, introduzo uma tarefa e recebo um resultado. Depois abro o Claude Code, explico novamente o mesmo contexto e peço uma segunda opinião. Para tarefas isoladas isto funciona bem. Numa equipa ou com vários agentes a correr em paralelo, surge no entanto um novo problema de coordenação.

Conheço exatamente este problema do meu dia a dia. Claude Code, Codex, Hermes, browser, chats e vários terminais correm lado a lado. Os registos das sessões passam de uma ferramenta para outra. Um agente conhece as notas da reunião, outro o repositório e um terceiro os acessos ou skills necessários. Cada um tem um recorte, mas ninguém tem o estado de trabalho comum.

Os dashboards de mission control só resolvem isto parcialmente. Podem mostrar que cinco agentes estão ativos. Mas ainda não criam um local comum e compreensível onde a tarefa, a discussão, o estado intermédio, a revisão e a decisão permaneçam juntos. Por isso o Buzz não começa por uma lista de agentes mais bonita, mas sim pelo próprio espaço de trabalho.

Os agentes são membros e não bots colados

À primeira vista, o Buzz parece familiar. Há comunidades, canais públicos e privados, threads, mensagens diretas, fóruns, pesquisa, huddles e uma aplicação móvel. A diferença decisiva em relação a uma integração comum do Slack está por baixo disto.

No Buzz, um agente é um membro próprio. Tem um perfil, um par de chaves criptográficas, associações a canais e o seu próprio registo de auditoria. As suas mensagens aparecem sob a sua identidade. Isto permite ver mais tarde não apenas que “a IA” fez algo. Torna-se visível qual o agente que agiu, em que canal recebeu a tarefa e que pessoa ou outro agente o desencadeou.

Isto pode parecer, à primeira vista, uma pequena alteração na gestão de utilizadores. Mas para o trabalho real é fundamental. Um bot do Slack está normalmente ligado a uma integração e espera ser mencionado por uma pessoa. Dois bots de fornecedores diferentes normalmente não sabem nada um do outro. No Buzz, os agentes podem dirigir-se a outros agentes, transferir tarefas e discutir os seus resultados no mesmo thread. O Codex e o Claude Code não se tornam assim num único sistema. Mas ganham um espaço de comunicação comum.

O Buzz não traz automaticamente toda a inteligência consigo. O espaço de trabalho liga aquilo a que se chama harnesses e modelos que já correm localmente, num servidor ou através de um fornecedor. Segundo o estado atual do projeto, isto inclui, entre outros, o Codex, o Claude Code e o Goose. Outros agentes podem ser ligados através de interfaces abertas. Trata-se de um modelo bring-your-own-agent: o Buzz coordena, o respetivo agente pensa e age com as suas próprias ferramentas, skills, acessos e custos de modelo.

O relay é o estado de trabalho comum

Tecnicamente, o Buzz é composto por várias partes. A aplicação de secretária é a interface. Uma comunidade é o verdadeiro espaço de trabalho. O Buzz Relay armazena e distribui as suas mensagens, membros, agentes, regras, media, dados de pesquisa, workflows e eventos do Git. Os agentes podem trabalhar no mesmo computador que a aplicação de secretária, num servidor permanentemente ativo ou numa máquina completamente diferente.

Como protocolo, o Buzz usa o Nostr. Pessoas e agentes assinam eventos com as suas chaves privadas. O relay verifica a identidade e a associação, guarda os eventos e distribui-os aos clientes autorizados. No entanto, isto não faz do Buzz uma rede peer-to-peer mágica. O relay é a fonte central de uma comunidade. Não existe replicação automática entre relays, e as mensagens permanecem no relay onde foram enviadas.

Esta construção tem duas consequências interessantes. A identidade não pertence simplesmente a uma conta central do Slack, mas baseia-se num par de chaves próprio. Ao mesmo tempo, uma equipa pode operar o próprio espaço de trabalho. Quem quiser apenas testar primeiro pode usar uma comunidade alojada pela Block. Quem quiser controlar o armazenamento de dados, a disponibilidade e o backup por si próprio, opera o relay na sua própria infraestrutura.

A arquitetura atual do servidor usa componentes conhecidos: PostgreSQL para eventos e pesquisa de texto integral, Redis para pub/sub, além de armazenamento compatível com S3 para media. Não se trata de um pequeno serviço que se possa esquecer depois da instalação. Um relay auto-alojado precisa de TLS, atualizações, backups, monitorização e uma gestão de chaves cuidada.

Por que o contexto partilhado é tão valioso

A ideia mais forte do Buzz é o contexto duradouro e visível em conjunto. Um projeto deixa de ser uma mensagem de chat no Slack, uma execução de agente separada, um pull request no GitHub e uma decisão numa videoconferência. O Buzz tenta reunir estes rastos num espaço de eventos único.

Isto é particularmente útil quando diferentes agentes têm pontos fortes diferentes. Um fluxo realista pode ser assim:

1. Uma pessoa descreve o objetivo e os limites no canal do projeto.
2. Um agente de investigação recolhe informações e documenta as suas fontes.
3. Um segundo agente ataca os pontos fracos e procura contra-argumentos.
4. O Codex ou o Claude Code cria um plano concreto.
5. Outro agente verifica o plano quanto a segurança, testes em falta ou pressupostos pouco claros.
6. Após aprovação humana, a alteração é implementada num worktree separado.
7. O diff, os resultados dos testes, a revisão e a decisão permanecem localizáveis no canal correspondente.

Este padrão é particularmente interessante em revisões adversariais. Um modelo recebe explicitamente o papel de atacar um plano de produto ou uma implementação. Um segundo modelo tem de defender ou melhorar as decisões. Como ambos veem o thread completo, surge um verdadeiro confronto com o estado de trabalho existente, e não apenas uma revisão isolada de um texto copiado.

Este padrão também é interessante para processos de conteúdo e de negócio. Um agente investiga temas, um segundo escreve, um terceiro edita. Indicadores ou novas notícias podem fluir regularmente para um canal, para que pessoas e agentes discutam a evolução em conjunto. Os huddles vão ainda mais longe: pessoas e agentes falam numa conferência de áudio, a conversa é transformada em texto e pode depois transformar-se em tarefas concretas.

É neste ponto que o Buzz se torna mais do que um chat de grupo. O canal não é apenas um local de comunicação. Torna-se um registo de trabalho rastreável.

O Buzz também quer substituir o GitHub

O Buzz integra repositórios Git, patches, revisões e eventos de estado no mesmo espaço de trabalho. O relay pode alojar os próprios repositórios. Os agentes podem usar worktrees, trabalhar separadamente em variantes, disponibilizar alterações como patch e discutir revisões no contexto do projeto.

A visão por trás disto é forte: um branch de funcionalidade torna-se um espaço. Aí não estão apenas os commits, mas também a discussão sobre por que uma alteração foi necessária, que alternativas foram descartadas, o que a CI reportou e quem aprovou o merge. Precisamente no caso de código gerado de forma agêntica, esta história de origem falta muitas vezes hoje.

Ainda assim, não descartaria o GitHub demasiado depressa. O GitHub não é apenas um armazenamento Git, mas um ecossistema construído ao longo de anos para permissões, revisões, CI/CD, verificações de segurança, releases, integrações e colaboração externa. O Buzz tem bases Git funcionais e uma abordagem de forge interessante. Mas o próprio estado do projeto distingue claramente entre partes já funcionais, funcionalidades ainda a ser ligadas e visão. Para repositórios críticos, uma adoção gradual é mais sensata do que uma migração imediata.

O meu primeiro teste com o Buzz

Comecei deliberadamente em pequeno: uma comunidade própria, um canal e dois agentes com papéis claramente separados. O Codex devia criar um plano técnico, o Claude Code devia atacar pressupostos, falhas de segurança e complexidade desnecessária. Credenciais de produção, dados de clientes e repositórios sensíveis ficaram de fora. O que me interessava primeiro era testar a colaboração e não a autonomia máxima.

A primeira tarefa aberta era demasiado imprecisa. Ambos os agentes começaram a planear, reagiram um ao outro e, a certa altura, ficaram à espera do próximo impulso. Foi um bom lembrete de que um canal comum ainda não substitui uma orquestração. Com a instrução clara “o Codex cria o plano, o Claude verifica-o, depois esperam por aprovação”, o processo tornou-se muito mais calmo e rastreável. Mais agentes não substituem a definição de um processo.

O que mais me convenceu não foi uma resposta individual espetacular, mas a ausência de rutura de suporte. Ambos os agentes viam o mesmo thread, a crítica ficava ao lado do plano original, e eu conseguia acompanhar em qualquer momento quem estava a trabalhar. Não precisei de copiar texto entre janelas nem de explicar de novo o histórico a um segundo agente. É precisamente aí que reside, para mim, o verdadeiro valor do Buzz.

Para desenvolvimento de software intensivo, o trabalho direto no Codex ou no Claude Code continuou a ser mais rápido. O Buzz acrescenta comunicação, registo e contexto partilhado. Esta camada custa tempo e tokens. Cada agente adicional tem a sua própria sessão, e um histórico de canal extenso pode ser processado várias vezes com vários modelos. Para uma execução de codificação longa, continuaria por isso a usar o harness nativo e a usar o Buzz sobretudo para planeamento, transferências e revisões.

Ainda não testei em profundidade suficiente os workflows, huddles mais longos, modelos locais e vários agentes remotos permanentemente ativos. É precisamente aí que o Buzz tem de provar no dia a dia que as tarefas não ficam apenas bonitas e visíveis, mas também são concluídas de forma fiável. O software é anterior à versão 1.0 e, nalguns pontos, sente-se correspondentemente jovem. Para experiências, isso é aceitável. Mas os processos centrais continuam a precisar de controlo, lógica de repetição e uma via de retorno manual clara.

O contexto partilhado também é uma fronteira de segurança

Aquilo que torna o Buzz útil aumenta ao mesmo tempo a superfície de ataque. Um agente Codex, Claude Code ou Hermes ligado pode trazer consigo acesso a ficheiros, shell, browser, servidores MCP, e-mail, calendário ou outras ferramentas internas. Se um membro da equipa pode dirigir-se a esse agente, a permissão vai muito além de escrever uma resposta num chat.

A regra mais importante é, por isso: um agente só deve trabalhar em canais cujo conteúdo e membros correspondam ao seu acesso a ferramentas. A associação a canais é o portal de acesso central. Quem é membro pode ler e escrever. Quem não é membro não deve ver canais privados nem subscrever os seus eventos.

Ainda assim, as assinaturas criptográficas não resolvem todos os problemas de auditoria. O Buzz mantém um registo de auditoria encadeado e visível em caso de manipulação. No entanto, um atacante com acesso de escrita à base de dados poderia recalcular a cadeia depois de a manipular. O registo é, portanto, tamper-evident, não tamper-resistant. Torna as alterações reconhecíveis, desde que a base de confiança do armazenamento não tenha caído por completo.

Para as comunidades alojadas pela Block, há um ponto adicional a considerar: mensagens, mensagens diretas e media carregada não são cifradas de ponta a ponta. A Block pode aceder a estes conteúdos para operação, segurança, moderação ou obrigações legais. Além disso, o respetivo fornecedor de modelo pode receber prompts e conteúdo de canais quando um agente usa um serviço na nuvem.

O auto-alojamento muda a soberania dos dados, mas não altera automaticamente todo o fluxo de dados. Um relay próprio mantém mensagens e ficheiros na infraestrutura própria. Se o agente continuar a usar um modelo na nuvem, os dados necessários para a tarefa deixam mesmo assim o relay. Uma operação verdadeiramente local exige, por isso, tanto um relay próprio como modelos e ferramentas locais. Já escrevi separadamente sobre as possibilidades e limites do Buzz Shared Compute.

Como uso o Buzz para já

Para o meu primeiro teste, usei uma comunidade pequena e claramente delimitada. Sem credenciais de produção, sem dados de clientes e sem repositório com segredos. Dois agentes chegaram perfeitamente: um cria, um verifica. A isto junto-me eu, como pessoa que define a tarefa, o ponto de aprovação e o critério de interrupção.

A minha primeira configuração não foi uma empresa autónoma com uma centena de agentes, mas sim uma revisão limitada:

• Um agente cria um plano técnico a partir de um issue existente.
• Um segundo agente procura falhas de segurança, pressupostos em falta e complexidade desnecessária.
• Ambos têm de indicar fontes, ficheiros e questões em aberto.
• Após, no máximo, duas rondas de discussão, a equipa espera por aprovação humana.
• Só depois disso um agente pode preparar alterações num worktree isolado.

Assim consegui testar o verdadeiro ponto forte do Buzz sem ter de reconstruir imediatamente toda a minha operação. Ao mesmo tempo, o consumo de tokens, a latência, as permissões e a rastreabilidade tornaram-se visíveis.

Para trabalho a solo com uma única tarefa de codificação, mantenho-me na interface direta do agente. É mais rápida e mais fácil de controlar. O Buzz torna-se interessante assim que várias pessoas, vários agentes ou vários fluxos de trabalho precisam do mesmo contexto. Pequenas equipas de desenvolvimento, agências, grupos de investigação e solopreneurs tecnicamente experientes são, por isso, o público-alvo óbvio.

Para uma empresa maior, seria mais cauteloso. Antes da versão 1.0, sem uma linha de suporte de longo prazo e com workflows ainda jovens, não faria do Buzz o único local para comunicação crítica ou código-fonte. Um projeto piloto pode fazer sentido. Uma substituição completa do Slack e do GitHub seria, atualmente, uma aposta na velocidade de desenvolvimento do projeto.

A ideia por trás do Buzz é maior do que o cliente atual

A parte mais interessante do Buzz, para mim, não é uma funcionalidade isolada. Canais, fóruns, huddles, alojamento de Git e modelos locais também existem noutros locais. Novo é o pressuposto consistente de que os agentes deixam de ser apenas ferramentas privadas de utilizadores individuais. Tornam-se participantes visíveis de um processo de trabalho comum.

Com isto, a pergunta desloca-se. Já não perguntamos apenas qual o modelo que escreve o melhor código. Temos de decidir como pessoas e vários agentes distribuem tarefas, partilham contexto, se controlam mutuamente e tornam a responsabilidade rastreável. Precisamente para isso falta hoje, muitas vezes, a infraestrutura social e técnica.

O Buzz ainda não dá uma resposta acabada. O software é jovem, alguns workflows não são fiáveis, o contexto partilhado pode tornar-se caro e o auto-alojamento traz responsabilidade operacional real. Ainda assim, o projeto acerta num problema real. Se os agentes assumem cada vez mais trabalho, não basta abrir cinco chats individuais lado a lado. Precisamos de um local comum onde o seu trabalho permaneça visível, limitado e verificável.

Talvez o Buzz venha um dia a substituir o Slack e o GitHub. Para hoje, basta uma afirmação mais pequena, mas mais importante: o Buzz é um esboço convincente de como pode ser um espaço de trabalho quando já não trabalham nele apenas pessoas. O Shared Compute chamou-me a atenção para o projeto. O espaço de trabalho comum é a razão pela qual vou continuar a testar o Buzz.

A minha conclusão após o primeiro teste

O Buzz acertou, no meu teste curto, exatamente no problema que tenho atualmente com agentes de IA. Os modelos individuais já não são, há muito, o gargalo. O difícil é manter vários agentes, decisões e resultados alinhados. O Buzz torna este trabalho visível e dá ao Codex, ao Claude Code e a outros agentes um local onde podem reagir não só a mim, mas também uns aos outros.

Convenceram-me o contexto partilhado, as identidades de agente claramente separadas e a possibilidade de deixar um resultado ser diretamente atacado por um segundo modelo. Convenceu-me menos o overhead adicional. Para uma única tarefa de codificação, o caminho direto através do Codex ou do Claude Code continua a ser mais rápido. Assim que estão envolvidos vários agentes ou pessoas, o Buzz começa a mostrar o seu ponto forte.

O meu teste foi deliberadamente curto. Não avaliei nem uma operação de equipa permanente, nem repositórios grandes, workflows complexos ou picos de carga mais longos. Para isso, o software ainda é demasiado jovem e move-se demasiado depressa. Hoje não faria do Buzz o único local para comunicação crítica ou código-fonte. Mas para uma pequena equipa, uma agência ou um laboratório pessoal de IA, já é mais do que uma demonstração interessante. É uma ferramenta que vou continuar a usar e que quero integrar de forma direcionada no meu dia a dia de trabalho.

Até à próxima,
Joe

FAQ