Quatro ações sobre as quais um agente deve sempre consultar um humano

A maioria dos sistemas de permissões para agentes de programação assenta em listas de permissões: ler ficheiros sim, escrever ficheiros sim, executar testes sim, perguntar tudo o resto. Isto funciona até alguém marcar um agente como «totalmente confiável» para silenciar os prompts, e o agente executar git push --force a uma sexta-feira.

A nossa posição é que quatro categorias de ações devem parar para intervenção humana todas as vezes, independentemente do nível de confiança no agente ou no autor do pedido. Os níveis de confiança decidem quantas outras coisas requerem aprovação. Estas quatro nunca ocorrem em silêncio.

As quatro

1. Enviar para um branch partilhado. Um commit num branch de funcionalidade é uma sugestão. Um push para a main ou release é uma decisão herdada por toda a equipa, frequentemente associada a um deploy. É uma ação barata de questionar e cara de reverter.

2. Apagar. Ficheiros, branches, tabelas, buckets, recursos. A eliminação é a única operação em que uma suposição errada sobre a intenção não pode ser desfeita por uma segunda tentativa. Os agentes são confiantes, e eliminações feitas com confiança são a forma como os backups acabam por ser testados.

3. Gastar dinheiro. Chamar uma API paga, aprovisionar um recurso, comprar um domínio, enviar uma campanha. Quem fez o pedido pode não saber que ele tem custos. Quem paga deve saber.

4. Aceder a credenciais. Ler um ficheiro de chaves, exportar variáveis de ambiente, iniciar sessão num serviço, concluir uma autenticação de dois fatores. Tudo aqui diz respeito a identidade, e a identidade pertence ao proprietário da máquina, não a quem estiver na sala.

Por que motivo a «confiança total» deve continuar a pausar aqui

Um modo de permissão descreve a relação de uma pessoa com o agente: apenas leitura, editar mas não fazer push, confiança total. Essa é a granularidade certa para as centenas de chamadas normais que um agente faz durante uma sessão. É a granularidade errada para as quatro categorias acima, porque são raras, irreversíveis ou dispendiosas, e porque o custo recai sobre alguém que não o autor do pedido.

Por isso, a regra no muti é simples: nenhum modelo de permissões pode configurar estas quatro para serem executadas silenciosamente. Mesmo no modo de «confiança total», elas param e são destacadas na timeline. O prompt é suficientemente raro para não ser incómodo, e as categorias são suficientemente precisas para que a resposta seja normalmente óbvia.

Como isto se mapeia nos modos de permissão do Claude Code

O Claude Code já possui uma escala: plan (apenas leitura), default (perguntar antes de edições e comandos), acceptEdits (edições executam-se, comandos perguntam) e bypassPermissions (nada pergunta). Esses modos descrevem quanto o agente lhe pergunta a si. As quatro ações descrevem o que deve perguntar ao proprietário quando outra pessoa está a fazer o pedido. Elas acumulam-se.

A última coluna é o acréscimo da sala e é idêntica em todas as linhas. Consulte modos de permissão explicados.

Quem deve ser consultado

Esta é a parte que a maioria dos desenhos ignora. Quando um agente partilhado precisa de um humano, qual humano?

• Credenciais vão para o proprietário. Inícios de sessão, códigos de dois fatores e acesso a chaves dizem respeito à identidade do proprietário. São encaminhados para o proprietário, independentemente de quem iniciou a tarefa. O autor do pedido vê que ocorreu uma tomada de controlo, não o segredo.
• Dúvidas sobre intenção vão para o autor do pedido. «Referia-se à base de dados de staging?» diz respeito ao que a pessoa pretendia. É encaminhada para quem fez o pedido.
• Ambos veem a mesma timeline. Nenhum deles precisa de transmitir contexto ao outro; a pergunta e a respetiva resposta ficam na mesma conversa que o trabalho.

Os prompts de credenciais e ações perigosas são encaminhados para o proprietário; as dúvidas de intenção vão para o autor do pedido; ambos veem a troca.

Anatomia de um bom cartão de aprovação

Uma aprovação que as pessoas conseguem decidir em cinco segundos tem cinco partes.

Disponibilize três botões: aprovar, rejeitar e continuar em modo apenas de leitura. A terceira opção é subestimada. Permite que o trabalho continue enquanto o passo de risco aguarda.

Permita que as aprovações sejam respondidas onde o proprietário já estiver: na consola, num telemóvel ou num cartão numa plataforma de chat. Decidir num local deve aplicar-se em todo o lado. Defina uma expiração para que um cartão esquecido não seja executado uma semana depois.

A fadiga de aprovação é o verdadeiro inimigo

Cada prompt condiciona quem o vê. Demasiados prompts, e o utilizador encontrará a definição para os desativar. Três práticas mantêm a taxa baixa sem afrouxar as quatro regras.

• Delimite o âmbito do agente. Um único diretório de trabalho por agente significa menos ficheiros em que ele poderia mexer, e menos prompts sobre mexer neles.
• Utilize os modos normais para chamadas normais. Apenas leitura para explorar, editar sem push para a maioria das tarefas. Reserve a «confiança total» para quem, de outro modo, estaria a digitar no seu teclado.
• Mantenha os modelos padrão honestos. Disponibilize apenas leitura, editar mas não fazer push e confiança total como predefinições com nomes claros, para que ninguém tenha de criar uma política de raiz e errar.

O registo de auditoria

Cada pedido e cada aprovação devem gerar uma linha que o proprietário possa exportar: quem pediu, quem decidiu, quando, qual regra, o que aconteceu, o que foi utilizado. Não porque alguém vá ler isso todos os dias, mas porque o dia em que algo corre mal não é o dia para começar a registar.

Perguntas frequentes

Perguntar todas as vezes não abranda o agente? Apenas nestas quatro categorias, que são raras numa sessão normal. O custo da pausa mede-se em segundos; o custo do erro mede-se em horas ou em dinheiro.

E se o proprietário estiver a usar o seu próprio agente? O proprietário não está sujeito a modos de permissão no seu próprio agente, mas as quatro ações continuam a ser registadas na timeline para que o histórico fique completo.

Um autor de pedido pode aprovar por si próprio? Não. A aprovação pertence ao proprietário da máquina. O autor do pedido pode Cancel, tentar novamente ou adicionar contexto.

As salas no muti vêm com estas regras ativadas de origem e sem forma de as desligar. Se isso lhe parece o padrão correto, dê uma sala ao seu agente.