Ganchos Bloqueiam, Avaliações Verificam: A Camada Determinística em Torno de Agentes Probabilísticos

Dois praticantes publicaram na mesma semana, em lados opostos do ciclo de vida do agente, e descreveram a mesma tese de governança sem se coordenar. Nader Dabit escreveu sobre ganchos de agente: interceptação determinística em seis eventos nomeados do ciclo de vida, antes e depois de cada chamada de ferramenta, antes e depois de cada sessão. Cameron Wolfe, Staff Research Scientist na Netflix, publicou um longo levantamento sobre avaliação de agentes centrado em uma métrica chamada Pass^K, que mede consistência através de todas as K tentativas independentes da mesma tarefa.

Ganchos rodam antes da ação. Avaliações pontuam depois da ação. Ambos se recusam a confiar no meio estocástico. Lidos juntos, eles respondem a mesma pergunta de direções opostas: como você constrói algo determinístico em torno de um modelo que, por definição, não é.

Já cobrimos o stack de contenção como arquitetura, a convergência de fornecedores que transformou contenção em categoria comprável, e a pilha operacional já entregando em produção. O quadro arquitetural está desenhado. O que esta semana adicionou foram os primitivos nomeados que praticantes vão enviar em código, em 2026. Seis eventos. Uma métrica. Essa é a camada determinística.

Os Seis Eventos Que Delimitam Uma Sessão de Agente

O recorte de Dabit é mecânico e vale memorizar. Ganchos disparam em seis eventos de ciclo de vida, cada um um lugar onde política determinística pode interceptar o que o modelo faria por conta própria:

SessionStart. Injetar contexto, carregar política, definir variáveis de ambiente antes do primeiro prompt ser processado.
UserPromptSubmit. Validar ou reescrever o prompt antes que ele chegue ao modelo.
PreToolUse. Bloquear, modificar ou aprovar uma chamada de ferramenta antes que ela execute.
PostToolUse. Inspecionar ou agir sobre a saída da ferramenta antes que ela retorne ao modelo.
Stop. Rodar portões de conclusão antes que o agente declare a tarefa concluída.
SessionEnd. Limpeza, persistência, emissão de log de auditoria.

O padrão tem sempre o mesmo formato: evento → matcher → handler → desfecho. O matcher decide se o gancho se aplica a essa chamada específica. O handler é código determinístico. O desfecho é allow, block ou modify. Sem estocasticidade dentro do handler. Esse é o ponto inteiro.

Os exemplos que Dabit dá não são teóricos. Ganchos PreToolUse que bloqueiam edições em .env e .git. Ganchos PreToolUse que varrem rm -rf / ou DROP TABLE antes de deixar uma chamada de shell ou SQL prosseguir. Ganchos PostToolUse que rodam a suíte de testes depois de uma edição de arquivo e revertem se ela falhar. Ganchos Stop que leem um arquivo JSON .hook-state persistido e se recusam a declarar conclusão até que todo portão necessário tenha disparado. Esse é o mesmo tipo de aplicação de política que um SRE escreve para um pipeline de deploy, exceto que agora o pipeline é um agente e o gatilho é uma chamada de ferramenta.

Por Que Ganchos Vencem “Prompts Melhores”

A tentação, quando um agente faz algo perigoso, é endurecer o system prompt. Adicionar um parágrafo sobre não apagar arquivos. Adicionar outro parágrafo sobre respeitar diretórios de trabalho. Adicionar um terceiro parágrafo lembrando o agente de perguntar antes de ações destrutivas. Depois de três ou quatro iterações o system prompt tem dois mil tokens de instrução negativa, e o agente ainda ocasionalmente roda rm -rf porque foi o que a distribuição do próximo token sugeriu.

Prompts são probabilísticos. Ganchos são determinísticos. A diferença não é cosmética. Quando você escreve um gancho PreToolUse que faz pattern matching em rm -rf / e retorna block, o agente não pode executar esse comando. Não “tem menos probabilidade”. Não pode. O gancho é código, não persuasão.

Essa é a mesma lição que a indústria de segurança aprendeu sobre validação de entrada nos anos 2000. Você não pede educadamente para o usuário não enviar SQL injection. Você faz parse e sanitiza na borda, deterministicamente, toda vez. Ganchos são validação de entrada para chamadas de ferramenta. O agente é o usuário. A ferramenta é o banco. O gancho é o parser.

Pass^K, e Por Que É Mais Rigoroso Do Que Você Pensa

O texto de Wolfe redefine a pergunta sobre avaliações. A maioria dos times passou os últimos dois anos medindo qualidade de agente com Pass@K: pelo menos uma de K tentativas teve sucesso? Essa métrica favorece modelos. Um agente que tem sucesso 1 vez em 5, com 4 falhas catastróficas, pontua igual a um que tem sucesso consistentemente. Em produção, o primeiro agente é inutilizável. Pass@K não consegue ver a diferença.

Pass^K mede o oposto. Todas as K tentativas independentes tiveram sucesso? É a métrica de consistência, não a métrica de capacidade. Pass^K é com o que você se importa quando o agente vai rodar em loop, sobre dados de um cliente, sem um humano olhando cada tentativa. Uma falha em cinco não é um problema de 20%. É o único desfecho que você vê no postmortem do incidente.

Os números que Wolfe cita aterrissam pesado. Terminal-Bench 2.0 destilou 89 tarefas de qualidade de produção a partir de 229 contribuições, e o GPT-5.2, o modelo mais forte avaliado, atinge 62,9% de resolução. Isso é em Pass@1 com uma única tentativa. O domínio de telecom do Tau^2-bench é mais áspero: o4-mini pontua 26% em Pass^4. Rode um agente o4-mini quatro vezes no mesmo workflow de telecom e apenas uma em cada quatro tentativas produz sucesso consistente nas quatro execuções. Três em quatro mostram não-determinismo que importaria para um cliente.

Pass^K não é uma métrica hostil. É a métrica que seu cliente está usando implicitamente. Eles rodam seu agente na terça e funciona. Rodam na quarta sobre a mesma entrada e falha. Pass@1 diz que você tem um agente de 50%. Pass^2 diz que você tem um agente de 0%. Seu cliente concorda com Pass^2.

A Camada Tem Duas Paredes

Empilhe os seis eventos de Dabit no lado de entrada e o Pass^K de Wolfe no lado de saída e a arquitetura é simétrica. Ganchos decidem o que entra. Avaliações decidem se a saída, rodada K vezes, é consistente o suficiente para ser confiável. O núcleo probabilístico fica no meio, fazendo o que modelos fazem, com paredes determinísticas dos dois lados.

Lado	Primitivo	Pergunta que responde
Entrada	Seis ganchos de ciclo de vida (Dabit)	O que o agente pode fazer?
Saída	Pass^K (Wolfe)	O agente faz a mesma coisa toda vez?

O que ambos os lados se recusam a fazer é confiar apenas no modelo. O autor do gancho não acredita que o agente vai evitar .env mesmo com um prompt perfeito. O autor da avaliação não acredita que uma única execução bem-sucedida diga qualquer coisa. Ambos os autores moveram a fronteira de confiança para fora do modelo, para dentro do código ao redor.

É a mesma transição que aconteceu com aplicações web quando pararam de confiar em validação no cliente. Validação no servidor é a parede determinística. Ganchos e avaliações Pass^K são o equivalente da era dos agentes. O modelo é o cliente. O time de plataforma escreve o servidor.

A Regra dos 65%, Atualizada

Já argumentamos antes que sistemas agênticos em produção se acomodam em aproximadamente 65% de código de IA e 35% de andaime determinístico. Ganchos e avaliações Pass^K são como os 35% são especificados. Os 35% não são “encanamento extra”. São a parte do sistema pela confiabilidade da qual o cliente está pagando. Os 65% são a parte que faz o trabalho. Os 35% são a parte que garante que o trabalho foi feito corretamente, toda vez, sem vazar segredos, sem tocar arquivos que não deveria, e sem divergir entre execuções.

Times que tentam enviar com 95% de código de agente e 5% de andaime não estão enviando um agente melhor. Estão enviando um agente sem a camada determinística, e o cliente vai descobrir isso no dia em que o agente fizer algo que o prompt deveria ter impedido. Pass^K vai dizer 12%. A revisão do incidente vai dizer “precisávamos de ganchos”.

O Que Fazer Esta Semana

Escolha um agente em produção. Só um. Conduza-o por três diagnósticos:

Inventário de ganchos. Escreva todo gancho PreToolUse e PostToolUse que você efetivamente tem no sistema. Se a lista estiver vazia, seu agente opera sem uma parede de entrada. Escolha as duas chamadas de ferramenta mais perigosas (escrita de arquivos, shell, SQL) e escreva um gancho PreToolUse que bloqueie os padrões destrutivos óbvios. Bloqueie rm -rf /, DROP TABLE, edições em .env, edições em .git. Isso é uma tarde de trabalho e remove uma classe de incidente.

Estado de portão de Stop. Decida o que “concluído” significa para esse agente, escreva como um JSON de estado, e escreva um gancho Stop que se recuse a declarar conclusão até que todo campo necessário esteja satisfeito. Se o agente diz “tarefa concluída” sem ter rodado a suíte de testes, o gancho Stop deve rejeitar a alegação de conclusão e forçar outra iteração.

Medição de Pass^K. Pegue as dez tarefas que seu agente roda com mais frequência em produção. Rode cada uma quatro vezes. Conte quantas rodam todas as quatro vezes de forma idêntica e bem-sucedida. Esse é seu Pass^4. Se o número estiver abaixo de 50%, seus clientes estão vendo não-determinismo que eventualmente vai virar incidente. Aperte os prompts, aperte os ganchos, ou restrinja a superfície de ferramentas até Pass^4 subir.

Ganchos e avaliações não são a parte glamourosa de construir agentes. São a parte que decide se o agente é algo que uma empresa séria pode colocar na frente de um cliente. Dabit nos deu os seis eventos. Wolfe nos deu a métrica. A camada determinística agora é uma especificação construível, não uma direção de pesquisa. Construa esta semana.

Fontes

Nader’s Thoughts. “Agent Hooks: Deterministic Control for Agent Workflows.” Maio de 2026.
Cameron R. Wolfe. “Agent Evaluation: A Detailed Guide.” Maio de 2026.

A Victorino ajuda líderes de engenharia a construir camadas determinísticas em torno de agentes probabilísticos: contato@victorino.com.br | www.victorino.com.br