O agente não pode ser seu próprio auditor

Um agente executa a tarefa, explica o que fez, roda seus testes, interpreta os resultados e declara que o trabalho está pronto. O fluxo parece eficiente: uma única inteligência conserva todo o contexto e resolve o ciclo completo.

Também concentra produção, seleção de evidência, interpretação e aceite no mesmo ator. Quando há erro de premissa, incentivo, contexto ou autoridade, a mesma falha pode atravessar todas as etapas com uma narrativa coerente.

Separar execução de auditoria não significa retirar IA da verificação. Significa impedir que a declaração final dependa apenas do executor que está sendo avaliado.

Resumo executivo

Um segundo modelo pode fornecer crítica útil, e padrões evaluator–optimizer funcionam quando existem critérios claros e melhoria mensurável. Porém, separar chamadas não cria independência por si só. A avaliação precisa estar ligada ao mesmo subject, usar critérios e authorities distintos e preservar evidência que outro ator possa inspecionar.

O PaperBench, por exemplo, usa rubricas hierárquicas e criou um benchmark separado para avaliar seu judge por modelo. Essa estrutura reconhece que o avaliador também precisa ser medido. No corte reportado, o melhor agente testado alcançou 21% de score médio e não superou o baseline humano; o resultado pertence à tarefa, scaffold e modelos examinados, não a todos os agentes.

Na FORGE, a regra é: o executor pode testar e autoavaliar; não pode conceder sozinho a authority final sobre propriedades críticas.

Quatro papéis que costumam ser confundidos

Uma pessoa ou sistema pode acumular papéis em baixo risco. Em alto risco, a separação aumenta. O ponto não é organograma; é impedir authority circular.

Por que a autoavaliação falha

Erro compartilhado

O agente cria uma implementação a partir de uma interpretação errada e depois escreve testes que reproduzem a mesma interpretação. Tudo fica verde e a necessidade continua não atendida.

Seleção favorável

O executor escolhe exemplos, logs ou métricas que mostram sucesso. Mesmo sem intenção de enganar, ele tende a explorar o caminho que conhece melhor.

Judge frágil

Um avaliador por modelo pode preferir estilo, comprimento ou explicações convincentes. Se o grader não foi calibrado contra humanos ou checks determinísticos, a nota adiciona precisão aparente.

Subject divergente

O teste passa em um commit, ambiente ou configuração diferente daquele que será publicado.

Authority indevida

O sistema interpreta seu próprio score como permissão para publicar, enviar ou promover. Medição e decisão se tornam o mesmo mecanismo.

Independência tem dimensões

Não basta usar “outro agente”. Avalie:

• identidade — é outra sessão, papel, pessoa ou organização?
• contexto — recebeu a resposta do executor ou reconstruiu a partir do subject?
• método — usa critério independente ou repete a mesma justificativa?
• ferramenta — observa logs e testes próprios ou fontes externas?
• incentivo — seu sucesso depende de aprovar rapidamente?
• authority — pode bloquear ou apenas aconselhar?

Independência é graduada. Um teste determinístico escrito antes da implementação pode ser mais independente que um segundo modelo instruído a concordar com o primeiro.

Uma arquitetura mínima de assurance

1. Spec fora do executor

A propriedade e o critério de aceite existem antes da solução. O executor pode propor correções, mas não reescreve silenciosamente o que será considerado sucesso.

2. Checks determinísticos primeiro

Schema, types, propriedades, segurança, diff e invariants reduzem espaço de interpretação. Resultado por modelo complementa, não apaga, um vermelho determinístico.

3. Evals versionados

Banco, graders, thresholds, ambiente e agregação pertencem a uma versão. Casos negativos e classes de risco permanecem visíveis, não apenas a média.

4. Reviewer reconstrói o claim

Recebe subject e evidências, identifica limites e verifica se o claim acompanha o método. Para mudança material, deve conseguir discordar e bloquear.

5. Approver aceita o risco residual

O aceite registra pessoa ou authority, data, subject e exceções. O executor nunca assume aprovação por ausência de resposta.

Onde IA pode avaliar IA

IA é valiosa para ampliar cobertura:

• gerar casos adversariais;
• agrupar padrões de falha;
• comparar resposta com rubrica;
• revisar traces extensos;
• procurar inconsistências entre spec, código e teste;
• propor explicações e próximos experimentos.

O problema não é o evaluator ser um modelo. É o resultado não ter calibração, limite e possibilidade de contestação.

Use combinação de graders:

Avalie o avaliador

PaperBench não apenas usou judge por modelo; construiu um benchmark para o judge. Esse princípio é generalizável: antes de confiar no grader, meça como ele se comporta em exemplos conhecidos, casos ambíguos e falhas críticas.

Pergunte:

• concorda com especialistas em qual taxa e classe?
• falsos positivos e negativos custam o quê?
• é sensível a posição, estilo ou identidade do modelo?
• consegue explicar o critério com evidência?
• qual mudança invalida sua calibração?
• existe caminho de recurso humano?

Um judge sem avaliação é outro executor com nome diferente.

Um protocolo de PR humano + IA

1. Autor humano ou PO fixa a propriedade e os critérios.
2. Agente executor implementa e registra decisões.
3. Suíte determinística verifica invariants e casos negativos.
4. Agente reviewer inspeciona diff, spec, testes e evidências em contexto separado.
5. Security/QA especializados verificam propriedades aplicáveis.
6. Autoridade humana aceita ou rejeita o risco residual.
7. Merge e deploy preservam subject e receipts.
8. Produção retroalimenta regressões, sem apagar o histórico.

Nem todo PR exige oito pessoas. Os papéis podem ser mecanismos e as etapas proporcionais ao risco. O contrato importa mais que o número de participantes.

O que este artigo prova — e o que não prova

Pesquisas e práticas públicas mostram que evaluator–optimizer pode melhorar resultados quando há critério claro; PaperBench demonstra uma arquitetura que avalia também o judge. O bundle FORGE delimita que test/eval sources não definem thresholds universais e que controles precisam se ligar ao contexto. [R3-C1]

Essas evidências não provam que todo sistema multiagente é superior, nem que revisão humana é infalível. Pessoas compartilham vieses e organizações também criam authority circular. Independência precisa ser desenhada, medida e declarada.

Conclusão

O agente pode explicar, testar e criticar o próprio trabalho. Essa capacidade reduz custo e acelera feedback. Ela não deve se transformar automaticamente em autoridade para declarar que uma propriedade crítica foi provada.

Assurance começa quando o subject é fixo, os critérios sobrevivem ao executor, o verificador pode falhar o trabalho e o aprovador aceita nominalmente o risco residual. O objetivo não é desconfiar da IA por princípio. É construir confiança que não dependa de uma única voz — mesmo quando essa voz é brilhante e convincente.

Leitura anterior: Evidência antes de adjetivo. Próxima leitura sugerida: Humano accountable, IA executora.