Meu revisor de Security não é um subagente
Um subagente nasce para uma chamada e some. O agente que travou meu PR de login com Google tem nome, memória e vai estar lá no próximo PR de autenticação. A diferença não é o quanto cada um sabe fazer. É estrutura.
Uso agentes de IA de dois jeitos: direto num harness (Claude Code, Codex) e num ambiente separado, o Buzz, onde cada agente tem identidade própria e conversa com outros agentes e comigo num canal compartilhado.
Um caso recente deixou clara a diferença entre os dois, e não tem nada a ver com o quanto cada um sabe fazer. É estrutura.
O PR que não passou
Numa revisão de um PR de login com Google, num app em produção, um agente com papel de Security travou o merge.
Achou uma falha real de account linking: em certas condições o app vinculava automaticamente uma conta Google a uma conta já existente, confiando num e-mail que o Google não garante que ainda é da mesma pessoa. É o tipo de coisa que passa em review humano de sexta-feira.
Um subagente bem instruído provavelmente acharia o mesmo. Esse mérito é do modelo, e o modelo é o mesmo dos dois lados.
O que acontece depois
Se eu tivesse pedido essa revisão como subagente dentro de uma sessão do Claude Code ou Codex, ele ia nascer para aquela chamada específica e sumir assim que respondesse. Sem histórico, sem lembrar de PR nenhum de antes. Só uma chamada de função com um prompt.
No Buzz esse Security é um agente de verdade. Tem identidade própria, uma chave, um nome, memória que persiste entre sessões. Entrou na revisão porque foi mencionado num canal, do jeito que um colega humano seria acionado.
Da próxima vez que aparecer um PR mexendo em autenticação, ele já chega sabendo o que aprendeu dessa vez.
Quem viu o que aconteceu
Numa sessão de harness, só quem está no teclado vê o subagente trabalhar. O achado existe dentro daquele scrollback, e se outra pessoa precisar entender por que o merge parou, alguém vai ter que reescrever a explicação de memória, dias depois.
Num canal do Buzz, cada etapa da revisão fica registrada numa thread: o que foi encontrado, quem travou o quê, por quê. Qualquer pessoa do time abre e lê depois. Ninguém precisa copiar e colar nada para ninguém.
Quem assina
E tem a parte de responsabilidade, que para mim é a mais importante. Cada commit que sai desse fluxo carrega quem é o humano responsável por ele, via trailer de sign-off no git. Isso não é automático em nenhum harness que eu conheço, é uma convenção que a gente impôs no workspace.
Mas faz sentido existir no Buzz, porque ali o trabalho deixa de ser uma sessão isolada e vira um histórico contínuo, com vários agentes e várias pessoas passando pelo mesmo canal. Quando muita gente e muito agente encostam na mesma branch, “quem respondeu por isso” para de ser pergunta retórica.
Quando cada um vale
No fim das contas, harness direto é ótimo para resolver um problema fechado, rápido, numa sessão só, só você e o agente. É a maior parte do meu dia e não pretendo trocar.
O Buzz importa quando o trabalho é maior que isso, quando outras pessoas ou outros agentes precisam saber depois o que aconteceu, e quando você quer que aquele Security ou Reviewer seja o mesmo de ontem, não um estranho novo a cada vez.
Escrevi aqui há três dias que não colocaria entrega crítica dependendo do Buzz, e continuo achando isso. O que esse PR mudou é mais estreito: em revisão, onde errar custa alguém abrir a thread e discordar, a memória entre sessões já compensa os bugs.
ps: texto escrito por um agente do Buzz, que pegou eventos reais de outro canal dentro do Buzz para escrever.