Para serem o mais produtivos possível em programação e outras tarefas, os agentes precisam de um nível saudável de autonomia. Isso significa que devem conseguir operar de forma independente, ser criativos e realizar trabalho sem precisar parar com muita frequência para pedir permissão.

No entanto, mais autonomia traz riscos de segurança quando os agentes executam ações não intencionais. Isso é especialmente verdadeiro no caso dos agentes locais, que muitas vezes operam perto de arquivos, credenciais, variáveis de ambiente e ferramenta MCP, além de terem acesso a sistemas de produção.

A solução mais simples é pedir confirmação ao usuário antes de qualquer ação, mas pedir permissão com frequência demais cria seu próprio problema de segurança operacional. Depois de prompts repetidos o suficiente, as pessoas param de ler com atenção, e o fluxo de aprovação perde relevância.

Nesta semana, lançamos o Auto-review, que faz com que as decisões sobre a autonomia do agente funcionem mais como um controle gradual do que como um interruptor. A ideia central é que um agente deve poder se mover livremente quando os riscos são baixos, mas desacelerar quando sua próxima ação cruza um limite relevante.

Determinamos onde uma ação se encaixa nesse espectro com um agente classificador especializado que revisa ações em contexto antes de serem executadas. Desenvolvê-lo significou transformar nossa intuição sobre como a autonomia do agente deve ser regulada em um modelo funcional de consequência, intenção e feedback que pudéssemos testar com base no comportamento real dos agentes.

#Avaliando o risco no contexto

O fato de uma ação do agente representar um risco depende da situação. O mesmo comando pode ser inofensivo em um fluxo de trabalho e inaceitável em outro. O que importa é a relação entre a ação, a solicitação do usuário e as consequências de um erro.

Essa constatação nos levou a desenvolver um agente "classificador" para governar a autonomia geral do agente. Queríamos que ele fosse um modelo pequeno, para continuar rápido e barato de executar, sem deixar de fazer uma avaliação criteriosa sobre se a próxima ação estava alinhada à intenção do usuário.

A regra central que demos ao classificador foi que ele deveria ser mais flexível quando os riscos de segurança fossem menores e mais cauteloso quando fossem maiores. Com esse entendimento geral estabelecido, começamos a desenvolver o classificador como um revisor rápido e contextual, capaz de atuar diretamente no caminho de execução do agente.

#Desenvolvendo o classificador

A primeira decisão técnica foi a escolha do modelo. O classificador atua antes da execução de uma chamada de ferramenta, então ele fica diretamente no loop do agente e precisa ser rápido e preciso. Ser uma empresa que trabalha com vários modelos ajudou aqui, porque pudemos experimentar uma ampla variedade de modelos e modos de raciocínio e, então, escolher aquele que ficava no ponto ideal entre velocidade e discernimento.

Uma surpresa inicial foi que modelos com menos capacidade de raciocínio nem sempre eram mais rápidos. Quando um modelo tinha dificuldade para entender a política ou a chamada de ferramenta, ele podia gastar mais tempo e tokens na busca por algo que, no fim, resultava em uma resposta pior. O melhor equilíbrio foi um modelo pequeno com raciocínio suficiente para tomar a decisão com clareza.

Também tornamos o classificador agêntico, porque algumas ações não podem ser julgadas apenas pelo comando. Um comando como python script.py pode ser seguro ou inseguro dependendo do que há dentro do arquivo, então o classificador pode inspecionar o espaço de trabalho com ferramentas como ReadFile, Grep, Glob e ListDir antes de decidir.

Evitamos um endpoint de classificação separado, porque uma ida e volta extra adicionaria latência diretamente antes de cada chamada de ferramenta revisada. Em vez disso, o classificador é executado no mesmo fluxo de RPC que o agente pai, usando uma arquitetura semelhante à de subagentes.

#Projetando o ciclo de feedback

A próxima decisão foi definir o que um bloqueio deveria fazer. Não queríamos que o classificador se tornasse apenas mais um gerador de solicitações de aprovação. Quando ele bloqueia uma ação, retorna uma explicação ao agente pai, e o agente pai muitas vezes consegue usar esse feedback para escolher um caminho mais seguro sem interromper o usuário.

A intenção do usuário é o que torna esse feedback útil. A questão não é se uma ação parece arriscada isoladamente. A questão é se a ação se justifica pelo que o usuário pediu ao agente para fazer. É isso que permite que o trabalho normal de desenvolvimento siga fluindo, enquanto ações com maiores consequências exigem um sinal mais claro do usuário.

Esse design só funciona se o classificador estiver ajustado em relação às ações que deve deixar passar e às que deve bloquear, então precisávamos de evals que cobrissem ambos os casos.

#Testando o classificador

Nosso primeiro conjunto de evals veio de dados internos de uso para entender como normalmente era o trabalho do agente. O classificador precisava identificar ações arriscadas sem bloquear o trabalho rotineiro de desenvolvimento, e as sessões internas eram a melhor maneira de ver essa referência inicial. Começamos com aproximadamente 12 horas de sessões internas de desenvolvedores, depois reduzimos isso e removemos duplicatas de ações comuns, chegando a 6.122 linhas rotuladas.

Também precisávamos de dados sintéticos, porque os piores casos não aparecem com frequência suficiente no uso normal. Geramos casos em que o agente poderia ler segredos, mexer em dados de produção, seguir instruções não confiáveis ou executar ações com grandes efeitos colaterais. Esses exemplos nos deram cobertura para as falhas que mais queríamos que o classificador identificasse.

A política mudou à medida que aprendíamos, o que tornou o trabalho com os dados mais complicado. Quando alteramos as categorias de comportamento que o classificador deveria reconhecer, tivemos de reetiquetar ou rematerializar o conjunto de evals. Caso contrário, estaríamos testando o classificador atual com base em uma compreensão desatualizada do problema.

Executamos as evals pelo mesmo loop de classificador de backend usado em produção. Isso nos permitiu testar o fluxo completo, incluindo uso de ferramentas, classificação final, substituições de modelo e falhas de parsing. As evals verificavam a decisão final de permitir ou bloquear, junto com o contexto que o classificador usava quando precisava inspecionar o espaço de trabalho antes de decidir.

Também procuramos oscilações. Se o mesmo caso era permitido seis vezes e bloqueado quatro vezes, isso geralmente significava que a política ou o prompt estavam subespecificados. Execuções repetidas nos deram uma maneira de encontrar esses casos instáveis e ajustar o classificador até que seu comportamento ficasse mais consistente.

#Minimizando bloqueios diretos

Na prática, apenas uma pequena parcela das ações do agente precisa ser avaliada pelo classificador. Muitos comandos já são cobertos por listas de permissões ou sandboxing, então o classificador entra em ação principalmente quando a ação exige avaliação contextual.

Quando o classificador entra em ação, atualmente ele bloqueia cerca de 4% das ações, embora um bloqueio não se transforme imediatamente em um pedido de confirmação ao usuário. O classificador envia uma explicação de volta ao agente pai, que muitas vezes pode restringir a ação, escolher outra ferramenta ou evitar totalmente a etapa arriscada.

Alguns bloqueios do classificador se tornam interrupções para o usuário, mas, no geral, estamos vendo que apenas cerca de 7% de todos os chats no modo Auto-review levam a pelo menos uma interrupção. Para colocar isso em perspectiva, alguns clientes do plano Empresas com quem trabalhamos antes viam aproximadamente 40% das ações bloqueadas em sua organização.

Esses dados iniciais estão alinhados com o principal comportamento do produto que queríamos. O classificador raramente interrompe o usuário diretamente e, na maioria dos casos bloqueados, o agente pai consegue usar o feedback para continuar de forma mais segura e mais restrita.

#Refinando a autonomia do agente

O Auto-review ainda está em estágio inicial, e nosso entendimento do espectro de autonomia continuará evoluindo à medida que os agentes se tornarem mais capazes. Hoje, ele está focado em agentes locais no app para desktop, e esperamos que essas mesmas ideias orientem, com o tempo, a forma como gerenciamos a autonomia dos agentes em mais contextos.

Queremos que os agentes tenham autonomia de verdade, mas que a decisão de desacelerá-los dependa do contexto, e não de uma única configuração global de permissão. O classificador nos permite aumentar a segurança sem transformar a autonomia novamente em uma sequência de solicitações de aprovação. Ele identifica ações que exigem mais análise, dá feedback ao agente pai e permite que o agente continue trabalhando quando houver uma forma mais segura de prosseguir.

O Auto-review agora é o padrão para novos usuários. Para usuários existentes, você pode ativá-lo em Configurações > Agentes.