Agentes de Quatro Fornecedores, Um Canal, Um Portão de Aprovação

Em 20 de agosto de 2026, o Gizmodo noticiou que o Slack lançou um recurso que permite marcar agentes de codificação por IA dentro de um chat em grupo. O Gizmodo relata que os agentes suportados vêm de quatro empresas concorrentes entre si: Anthropic, GitHub, Cognition e Vercel, com Claude Code, GitHub Copilot e Devin entre os citados. Uma conversa só, vários fornecedores, um conjunto de regras sobre o que qualquer um deles pode fazer.

Dois controles vêm junto, segundo o Slack. Fazer merge de código em produção exige aprovação humana. E, depois que o time aprova o trabalho, o agente arquiva o canal.

O arquivamento é o controle que merece leitura atenta.

Vários fornecedores entrando pela mesma porta

Cada harness de agente carrega o próprio modelo de aprovação. Eles discordam sobre o que conta como ação perigosa, sobre quanto tempo uma permissão concedida persiste e sobre o que o usuário enxerga antes de dizer sim. Colocar todos no mesmo canal não reconcilia esses modelos. Coloca um portão acima deles, que segundo o anúncio é a aprovação humana antes do merge em produção.

A fronteira se desloca. O fornecedor deixa de ser dono do último ponto de checagem e o canal passa a ser. Um time padronizado em um único agente tem o julgamento de um fornecedor para auditar. Um time usando o Slack Code tem o comportamento de vários fornecedores chegando pela mesma porta, o que é mais fácil de observar no momento do merge e mais difícil de raciocinar antes dele, porque cada agente continua decidindo sozinho o que propor antes de o portão ver qualquer proposta.

Existe uma questão de identidade embaixo disso. Cada um desses agentes age dentro de um workspace construído para pessoas, com lista de membros, participação em canais e histórico de mensagens desenhados em torno de contas humanas. Já argumentamos que um agente operando com alcance de funcionário é um insider não humano e precisa de isolamento compatível. Um chat em grupo é a superfície onde essa distinção é mais difícil de sustentar, porque o agente parece mais um participante da conversa e lê tudo o que a conversa contém.

O Gizmodo registra que o recurso está disponível em todos os planos do Slack. A revisão de compras sobre um agente de codificação deixa de ser o ponto de controle quando os agentes chegam dentro de uma ferramenta que a empresa já comprou. Ninguém assina contrato novo. Ninguém abre avaliação de risco de fornecedor. Os agentes simplesmente estão lá, num workspace que já contém quase toda a companhia.

O arquivo guarda a discussão

Segundo o relato do Gizmodo, o agente arquiva o canal depois que o time aprova o trabalho, e as pessoas podem revisar uma prévia em HTML antes de aprovar.

Arquivar um canal de trabalho é um controle de governança que chegou sem receber esse nome. Pense no que uma revisão de código normalmente descarta. A abordagem alternativa que alguém levantou e abandonou. O motivo de um teste ter sido pulado naquela vez. Quem pediu a mudança, e com que palavras. Um pull request retém o diff e os comentários grudados no diff. Um canal retém a deliberação que produziu o diff, inclusive as partes que nunca viraram artefato formal.

Esse registro é mais útil que o histórico de commits quando você quer entender por que um sistema se comporta como se comporta. Também é material passível de descoberta judicial, parado num sistema cuja política de retenção a sua organização escreveu para conversas e não para decisões de engenharia. A maioria dos procedimentos de legal hold cita e-mail, sistemas de ticket e repositórios de documentos. Um canal arquivado com a discussão inteira por trás de uma mudança em produção é uma categoria nova, e o time que a produziu geralmente não sabe dizer quanto tempo ela sobrevive nem quem consegue ler daqui a dois anos.

Já escrevemos sobre registrar a fronteira de escalonamento como artefato. O Slack Code produz esse artefato independentemente da intenção de alguém, o que levanta uma pergunta diferente da que fizemos lá. A entrega está registrada. Falta saber quem governa o registro.

Leia o portão como descrição do fornecedor

Gianna Dimick, porta-voz do Slack, descreve “aprovação humana em ações de alto risco, como fazer merge de código em produção”. Katie Steigman, VP de produto, descreve o modelo de trabalho como um em que “o time inteiro e o agente trabalham juntos na construção”.

As duas declarações vêm do Slack, sobre o Slack. O Gizmodo não publica números de adoção, dados de uso nem qualquer teste independente do portão. O que sabemos é o que o fornecedor diz que está no produto, uma afirmação sobre funcionalidade e não uma medição de controle. É o mesmo padrão que acompanhamos quando governança virou funcionalidade de produto em três fornecedores: o controle é anunciado como capacidade, descrito por quem o vende, e adotado por clientes que passam a tratar a descrição como garantia.

Nossa posição sobre pedidos de aprovação está registrada: um prompt de permissão por ação não é um controle, porque depende de um revisor atento e o desenho garante a desatenção. Um portão de merge dentro de um canal herda essa fragilidade e acrescenta outra. Num pull request, o aprovador é um revisor nomeado, com papel e obrigação de revisão. Num canal, o aprovador é quem estiver presente e responsivo. Presença não é modelo de permissão. Se quem aprova um merge em produção às 18h de sexta é a pessoa que estava com o app aberto, o portão registra um nome sem registrar responsabilidade.

A prévia em HTML corta na direção oposta. Ter algo revisável antes da aprovação é uma melhora concreta sobre ler um diff no terminal. Se o arquivo registra quem de fato abriu a prévia é uma pergunta para o fornecedor.

O que uma política de governança de chat precisa responder

A maioria das organizações tem política de revisão de código, política de acesso a produção e política nenhuma para a superfície de chat como lugar onde decisões de produção são tomadas e guardadas. Quatro perguntas ficaram abertas.

Quem pode aprovar um merge em produção a partir de um canal, e essa lista é a mesma das pessoas que aprovam no repositório? Se as duas listas divergem, a superfície de chat é um desvio.

Qual é o prazo de retenção de um canal arquivado do Slack Code, e ele bate com o prazo de retenção do pull request correspondente? Deliberação que sobrevive ao código, ou que morre antes dele, produz um registro incoerente nos dois casos.

Quais agentes são permitidos num canal que toca código de produção, e quem decide? Vários fornecedores sob um portão só significa vários conjuntos de comportamento anterior que você não avaliou.

O arquivo entra em legal hold quando o repositório entra? Um regulador ou um advogado da parte contrária não vai aceitar que o raciocínio morava num sistema que ninguém lembrou de preservar.

Faça isto agora

Abra as configurações de administração do seu Slack e descubra se o Slack Code está habilitado no workspace. Ele está disponível em todos os planos, então a resposta provável é sim, e ninguém do seu time precisou pedir.

Depois pegue um merge recente em produção e escreva onde o raciocínio dele mora hoje. Se a resposta for uma thread de pull request, pergunte qual é o prazo de retenção dela. Se parte da resposta já for uma conversa no Slack, o problema de governança existe antes mesmo de o recurso chegar, e o Slack Code apenas deixa o registro completo o bastante para valer a discussão.

Por último, pegue a lista de quem pode aprovar um merge em produção e reconcilie as duas superfícies. É uma tarde de trabalho, e é o único controle aqui que não depende de acreditar na descrição que o fornecedor faz do próprio portão.

---

Fontes

• Gizmodo. “Slack Has (of Course) Launched a Vibe Coding Tool.” Agosto de 2026.

A Victorino ajuda organizações de engenharia a escrever política de governança para as superfícies onde o trabalho dos agentes de fato acontece: contato@victorino.com.br | www.victorino.com.br