Observando um agente com um modelo de decisão

Agentes de código são onde estes modelos são usados mais densamente, e os usos se agrupam em três lugares. Os três compartilham uma mesma estrutura: tire o julgamento do modelo generativo, dê-o a algo mais barato e mais rápido, e deixe o código agir sobre uma resposta tipada.

1. Antes de uma chamada de ferramenta: permitir ou não

O lugar mais direto. Um hook PreToolUse do Claude Code faz isto:

Pergunte a um Noul: este comando de shell é estritamente somente leitura? Aprove automaticamente em 0.95, caso contrário recorra ao prompt de permissão normal — e nunca negue.

Três decisões de projeto merecem ser nomeadas:

• 0.95 é alto. A barra para aprovar automaticamente fica bem acima da barra para “isto parece arriscado”. Uma permissão falsa custa uma máquina; um bloqueio falso custa uma confirmação extra. Custos assimétricos pertencem a limiares assimétricos.
• Ele nunca nega. Ele só adiciona uma aprovação; todo o resto retorna ao sistema original. Um gate que só adiciona capacidade é muito mais fácil de testar — seu pior caso é não ter ajudado em nada.
• Comandos perigosos nunca chegam ao modelo. Uma lista local de proibições e um filtro de injeção os capturam primeiro. Isto importa mais do que o limiar — veja O que precisa viver no código.

Resultado medido: 0 de 8 comandos que alteram estado foram aprovados automaticamente.

2. Quando o agente quer parar: já terminou?

Outro ponto frequente. Um hook Stop pergunta ao modelo de decisão se o agente está terminando cedo demais, apresentando a ele suas regras de conclusão em linguagem natural.

A versão mais contida funciona assim:

Gaste uma chamada de quatro perguntas só quando arquivos mudaram e nenhuma verificação aprovada rodou desde então. Falhe aberto em qualquer erro.

“Pergunte só quando vale a pena perguntar” é o ponto crucial para esta classe — esses hooks rodam a cada turno, e chamar incondicionalmente multiplica o custo pelo número de turnos. A condição acima é “mudanças não verificadas”, que é exatamente o momento em que um agente mais provavelmente declara vitória sem ter verificado.

Um hook relacionado impede que um agente termine cedo, julgando as regras de conclusão em linguagem natural em vez de confiar na própria alegação do agente.

3. Quando o contexto enche: o que ainda é necessário?

O terceiro ponto é a compactação de contexto, onde as abordagens mais divergem.

A compactação tradicional resume: entregue um trecho de conversa a um modelo e receba prosa de volta. O original se foi, e o resumo é irreversível.

A abordagem com modelo de decisão não reescreve — ela apenas pontua:

A frase compartilhada: o trabalho do modelo de decisão aqui é um julgamento binário de manter/descartar, não uma reescrita. É precisamente isso que ele faz bem e que os modelos generativos fazem mal — e “dobrar em vez de apagar” transforma um julgamento errado de “informação perdida para sempre” em “um expand a mais”.

O contraponto: gates de segurança e gates de eficiência falham em direções opostas

O contraste mais instrutivo desta parte do ecossistema: dada a mesma pergunta “o que acontece em caso de erro”, os projetos escolheram respostas opostas, e ambas estão certas.

• Um juiz de permissões: nega em erro ou timeout.
• Um hook Stop: permite em qualquer erro.

O critério não é “qual é mais seguro”, mas se este gate protege risco ou throughput. Gates que protegem risco (permissões, segredos, comandos perigosos) devem antes bloquear uma coisa boa do que deixar passar uma ruim; gates que protegem throughput (verificações de conclusão, verificações de formato) devem antes deixar passar algo do que travar o fluxo.

Em uma frase

Os agentes são o lar mais natural para estes modelos porque precisam de uma grande quantidade de julgamentos baratos cujos resultados são consumidos pelo código imediatamente. Mas em cada um desses pontos, decida primeiro: para que lado este gate deve cair quando quebra?