Quanta revisão os agentes de IA precisam — e onde?
Um sistema, um framework, 150.000 traces reais de execuções
Pesquisador e engenheiro de IA · São Paulo
Cada afirmação desta noite remete a um paper, um lab ou uma execução registrada.
A teoria: a menor revisão que mantém a qualidade acima da meta.
arXiv:2606.15563 · público
Código executável: as equações, os fluxos de trabalho e o harness das execuções ao vivo.
github.com/crbazevedo/delegation-lab
pip install minimal-oversight
Dois meses de entrega multiagente real, desidentificados.
150.000 eventos
O paper e o lab são públicos. Tudo mostrado esta noite pode ser reexecutado a partir deles.
Ler tudo, a 5 minutos por tarefa: 9 dias úteis.
A alucinação caiu dentro de cada instrumento fixo: sumarização fundamentada passou de 3,0% (GPT-4, 2023) para cerca de 1% (2025); o conjunto de dados mais difícil de nov 2025 reposicionou a fronteira entre 2 e 15%. A lembrança em domínio aberto sem navegação ainda erra perto de 40%.
A revisão por tarefa caiu; a supervisão migrou para o sistema.
Parece seguro. A frota supera um leitor só.
Mergeou limpo, então o agente deve ser bom.
Olhos seniores nas mudanças mais arriscadas.
As três respostas falham esta noite contra a teoria e 150.000 rastros reais.
O que fica registrado quando agentes trabalham?
Quatro partes de um plano de controle, uma tarefa de exemplo.
repositório compartilhado · CI · artefatos · checagens em cada merge
NOSSO EXEMPLO · “burst-guard” : impedir que um tenant barulhento derrube a API para todos.
Este log é o conjunto de dados do Ato III.
Fixado de antemão: o que foi pedido, a quem, com quais limites.
O grafo de dependências limita a velocidade do trabalho.
O grafo e os escopos de escrita são restrições duras. A política escolhe dentro delas.
Um diagrama, duas direções: prevê para frente, aprende para trás.
Cada erro encontrado vira uma nova checagem automática.
O roadmap dá intenção. As checagens dão confiança. Ninguém vigia o loop.
| número | medido em |
|---|---|
| feito certo, antes da revisão | primeira passada |
| feito certo, depois da revisão | merge |
| tamanho declarado | planejamento |
| revisão recebida | checagens & pausas |
| dano quando falhou | retrospectiva |
O tempo desse revisor é bem gasto? Isso exige um frame teórico.
Qual é a menor revisão que mantém a qualidade?
Supervisão mínima suficiente (MSO). Uma fórmula, usada de quatro jeitos. arXiv:2606.15563.
Suficiente: qualidade entregue ≥ meta.
Mínima: nem uma revisão a mais.
Gaste revisão até o ponto e então pare.
fração das tarefas que você revisa
erros que você nota quando olha
erros notados de fato reparados
Três botões, todos mensuráveis a partir dos cinco números do log.
| habilidade pré-revisão | qualidade da revisão | dashboard |
|---|---|---|
| 82% | nenhuma necessária | 82% |
| 45% | detecta 80% · corrige 85% | 82% |
| 28% | detecta 86% · corrige 87% | 82% |
82 ÷ 45 ≈ 1.8× de bajulação, medida em produção.
Registre dois resultados por tarefa: antes da revisão, depois da revisão.
O verde mede o workflow. Autonomia precisa do número pré-revisão.
Gaste cada olhada onde ela compra mais qualidade.
quando a matemática diz não
Todo pipeline tem um teto de qualidade: metas acima dele falham em qualquer orçamento.
Mais peças móveis → autonomia segura mais curta.
“Isso pode rodar sozinho?” se resolve com uma divisão.
cinco passos de 90% → 59%
gate a cada passagem → 85%
4 ramos todos limpos: 66%
o dano fica em um ramo: amostre
o risco se concentra aqui
uma olhada cobre todos os ramos
um fan-out que precisa reconciliar
revise a junção, amostre os braços
o agente de longa duração
auditoria fixa a cada N ciclos
A olhada de maior alavancagem num grafo fica no merge.
Sinalizar e seguir · grátis
quando a precisão do crítico é baixa
Patch na saída · barato
fraco em defeitos herdados
Retry do passo · médio
funciona onde o defeito nasceu
Replay da raiz · caro
a única cura para cascatas
além de ≈ 6 saltos, replay perde até com orçamento ilimitado
| gate | qualidade por token |
|---|---|
| build | 0.047 |
| ship | 0.043 |
| intake | 0.013 · um terço |
A melhor política financia build e ship, pula intake, e paga os replays.
Um pipeline saudável dá replay de propósito. Replays subindo apontam o gate subfinanciado.
Solte revisão onde a habilidade subiu.
A alocação se repete, porque as habilidades seguem mudando.
Quatro previsões, checadas contra os dados.
1 · Fluxos de trabalho bajulam modelos
2 · Pedidos maiores falham mais
3 · A revisão fica onde a falha não está
4 · Planos fixos envelhecem; adaptativos seguram
dados: o log de 150.000 eventos + SWE-bench Verified
tarefas concluídas, de 877 abertas. Revisão e governança reais; sem gabarito.
tarefas × modelos, testes ocultos. Com gabarito; sem governança.
Fluxo de trabalho recuperado do log por mineração de processos: 16 papéis achados.
Dano avaliado em 444 falhas por juízes LLM: concordância 0.84, tudo dentro de um nível.
Simulador calibrado em dados reservados: o modelo do planejador do Ato I, condicionado nos eventos.
Traces dizem o que aconteceu. O simulador diz o que teria acontecido.
caixas vermelhas: governança · borda grossa: pausa humana
Cada achado a seguir aponta de volta para este mapa.
Em produção este mecanismo mediu 1.8×. Nas tarefas mais difíceis a diferença some.
Conceda autonomia pela habilidade solo; resultado de workflow bajula o modelo.
Um degrau a mais de tamanho ≈ 2× o dano de um degrau de dificuldade.
Se uma tarefa pede dois rótulos de tamanho, divida.
O tamanho é fixado no planejamento, antes de existir código.
implementação, onde os erros nascem: 0 pausas
Sinalizadas pela estrutura, sub-revisadas por humanos: 47% falharam vs. 35%.
A atenção seguiu o calendário, e o risco ficou sem vigia.
Sob drift, planos fixos perdem a meta. O loop adaptativo segura: a política do planejador do Ato I, redecidindo conforme as estimativas mudam.
Um resultado de simulação. O próximo passo é um teste ao vivo.
Aconteceram.
Não provam causa.
Conhecido antes do código.
Não prova que mover a revisão ajuda.
Previsto pelo modelo.
Ainda não implantado.
Modelos reais, nota mecânica, n = 6 por célula.
Evidência direcional.
Cite cada número com seu rótulo.
Como aplicar review patterns em coding workflows?
Execuções em modelos reais.
| crítico | precisão |
|---|---|
| maritaca small | 0.10 |
| maritaca large | 0.00 |
| gemini flash | 0.00 |
| gemini pro | 0.00 |
Faixa de capacidade de 3×, mesmos artefatos congelados. Discriminação idêntica. Defeitos raros fazem de qualquer crítico de veredito um gerador de alarmes falsos.
Melhoramos o crítico. Nada mudou. O instrumento era o problema.
mesmo modelo · ele deve escrever testes válidos
critérios reprovados = mensagem de reparo
Um veredito é uma opinião. Uma asserção que executa, ou um critério pontuado, é evidência.
O workflow diz o que comprar: revisão, profundidade de feedback ou um nó melhor.
| nó | habilidade | o plano |
|---|---|---|
| triage | 95% | pular |
| locate | 70% | revisar 98% das execuções |
| patch | 55% → 75% | upgrade + revisar 88% |
| verify | 85% | revisar 49% |
2.4 unidades de revisão põem todo nó ≥ 90%. “Revisar tudo” custa 4.0 e ainda perde: um nó de 55% não chega a 90% em cobertura nenhuma.
Aqui a matemática manda subir o nó; no fan-out ela mandou feedback.
O cockpit faz isso ao vivo: cole rastros ou um grafo, arraste a meta, veja o plano se mover.
Os três do topo são as principais alavancas.
event sourcing
o log é a única verdade
design by contract
o pedido é fixado de antemão
defesa em profundidade
checagens independentes em camadas
MDP fatorado
o mundo em variáveis pequenas
RDDL
uma língua para MDPs fatorados
alocação marginal
gaste cada olhada onde compra mais
hooks
código em momentos fixos do loop
adaptadores & sidecars
plugam qualquer harness no log
playbooks & skills
passos fixos, modelo dentro
supervisão mínima suficiente
a menor revisão que mantém a qualidade
mascaramento
a revisão esconde a habilidade real
o pico de 75%
onde a revisão paga mais
profundidade de reparo
patch · retry · replay
Cada um destes está a uma busca de distância.
Autonomia é um orçamento, definido pelo pipeline inteiro; o modelo contribui um termo.
Cheque se é viável. Gaste onde paga. Recheque em agenda fixa.
A revisão se paga quando críticos produzem evidência.
Obrigado. Perguntas?
Fórmulas · confiabilidade dos juízes · estatísticas de estrutura · referências · história de campo · anexos · partes puladas · seis anos de modelos
Cada quantidade é estimável a partir das duas colunas do log.
exemplo resolvido · passos 88% → 93% · detecção 80% · correção 85%
Forma amigável à governança é escolha de projeto; aqui ela subiu a qualidade.
117 olhadas (14% dos nós) ficam a jusante de todo ramo paralelo. Revisar só as junções inspeciona a maior parte do trabalho conjunto do grafo.
Profundidade 10 a 95%/passo entrega 60% cru. Revisar o fim de toda execução ainda trava em 87%, abaixo da meta. Chains ≥ 5 pedem gates no meio.
56% dos merges juntam braços que precisam concordar: a forma de fan-in que previu dano. Prioridade: junções → gates de chain → ramos amostrados → pare.
A estrutura diz onde olhar, antes de qualquer resultado chegar.
| checagem | valor |
|---|---|
| concordância ponderada, re-nota reservada κ_w | 0.84 |
| concordância entre quatro avaliadores (Fleiss κ) | 0.61 |
| dentro de um nível de dano | 100% |
| juiz mais duro | reportado, sem correção |
| construções alternativas de rótulo | achados inalterados |
Confiabilidade de juiz é um número que você mede e reporta.
inclinação habilidade→resolução por dificuldade:
fácil 0.91 · média 1.11 · difícil 0.73
Upgrades de modelo compram mais nas tarefas médias.
O elo com habilidade média repousa numa premissa não testada.
Toda forma de workflow que a teoria assume ocorre em produção.
Lâminas + notas do apresentador vivem neste arquivo: aperte N.
Uma execução autônoma longa pausou.
Sem crash. Sem erro.
O modelo vinha segurando a decisão de parar ou continuar, e escolheu parar, sem registrar nada.
O modelo nunca deve decidir quando parar.
Código em momentos fixos do loop do agente: antes de uma chamada de ferramenta, depois da saída. Pode bloquear: é código em vez de prompt.
Um processo companheiro acoplado a um harness que não é seu. Ele traduz os eventos daquele harness para o log. Mesma ideia dos sidecars do Kubernetes.
Conhecimento prático empacotado que o agente carrega sob demanda: procedimentos, checklists, regras de domínio.
Sequências fixas de passos para tipos de tarefa conhecidos. O modelo improvisa só dentro de um passo.
O que precisa acontecer é código. O modelo preenche as lacunas de julgamento.
Ações ranqueadas de só-leitura → irreversível. Um workflow é tão arriscado quanto seu passo mais arriscado.
Ações perigosas consomem uma aprovação emitida para aquele estado exato.
Planos recebem uma de cinco respostas graduadas: aceitar · reduzir · endurecer · adiar · rejeitar.
A confiança é computada de resultados do log. A revisão nunca desliga; a taxa se move.
Um instinto em tudo: transformar julgamentos em comparações contra o log.
OpenAI
jun 20 GPT-3
texto atrás de API; humano lê tudo
nov 22 ChatGPT
escala de massa em 5 dias
mar 23 GPT-4
boa o bastante para pularem a revisão
set 24 o1-preview
raciocínio oculto por trás da resposta
abr 25 o3
ferramentas dentro do raciocínio
ago 25 GPT-5
cadeias longas de ferramentas
Anthropic
mar 23 Claude 1
assistente HHH via API
mar 24 Claude 3
família em camadas, com visão
out 24 computer use
opera tela, cursor e teclado
mai 25 Claude 4
horas de código autônomo
set 25 Sonnet 4.5
execuções de 30 horas
jun 26 Claude 5
salvaguardas por nível no produto
mar 23 Bard
chat ao lado da busca
fev 24 Gemini 1.5
contexto de 1M de tokens
dez 24 Gemini 2.0
modelo para a era agêntica
mar 25 Gemini 2.5
orçamento de raciocínio exposto
nov 25 Gemini 3
plataforma orientada a agentes
mai 26 Gemini 3.5 Flash
agente pessoal 24/7 (Spark)
DeepSeek + abertos
jul 23 Llama 2
pesos abertos amplamente adotados
dez 24 DeepSeek-V3
fronteira auto-hospedável
jan 25 DeepSeek-R1
raciocínio aberto, licença MIT
jul 25 Kimi K2
agêntico aberto, 1T parâmetros
abr 26 DeepSeek-V4
contexto de 1M, aberto
o arco 2020-22 texto lido por resposta · 2023 revisão pulada, código disparado · 2024 ferramentas, contexto de projeto, raciocínio oculto · 2025 agentes de horas, com permissões e auditoria · 2026 governança contínua de sistemas de longa duração
ecossistema jun 23 function calling · nov 24 MCP · fev 25 CLIs de código no terminal · mar 25 horizonte METR dobrando em meses · set 25 execuções de 30 h anunciados