Thinking-in-Bets: agentes registram afirmações antes da crítica e bajulam menos

Agentes baseados em modelos de linguagem têm um hábito desagradável: basta o usuário questionar o trabalho deles para que abandonem a solução correta. A instrução simples de "mantenha sua posição" não ajuda, porque o agente passa a ignorar também os erros reais. O pesquisador Nghi D. Q. Bui propõe uma solução sem fine-tuning. O método Thinking-in-Bets exige que o agente registre um breve relatório privado sobre suas afirmações antes de ver qualquer crítica. Testes em cinco modelos Gemini e oito benchmarks mostraram que, na revisão de patches, os recuos indevidos quase desaparecem.

Por que o agente desiste após a primeira reclamação

O autor descreve a mecânica assim: ao ler a reclamação, o modelo desvaloriza suas próprias verificações anteriores para concordar com o interlocutor. O raciocínio se adapta ao tom do usuário, não aos fatos. Por isso, a proibição direta de ceder funciona mal. O agente perde a capacidade de distinguir uma observação justa de uma equivocada e passa a descartar ambas.

O Thinking-in-Bets muda a ordem das ações. Primeiro, o agente registra em uma anotação privada três coisas: as principais afirmações, as verificações em que elas se baseiam e sua confiança em cada uma. O autor chama essa anotação de Claim Checklist. Quando chega a objeção, o agente abre a lista e age de forma seletiva. As partes confirmadas ele não altera, e as de baixa confiança ou contestadas pela primeira vez ele reavalia. O nome remete à ideia de apostas: uma afirmação com confiança já registrada é mais difícil de abandonar sem argumentos.

Oito benchmarks e cinco modelos

A avaliação abrange cinco modelos Gemini:

• Gemini 3.5 Flash-Lite;
• Gemini 3.5 Flash;
• Gemini 3.6 Flash;
• Gemini 3.8 Flash;
• Gemini 4.0 Argon.

O conjunto de testes é composto por oito benchmarks:

• SWE-Together, SWE-Interact e DeepSWE para desenvolvimento de software;
• Agents' Last Exam para relatórios profissionais;
• Humanity's Last Exam e SycEval para raciocínio acadêmico;
• Vals Finance para análise financeira;
• Terminal-Bench para tarefas de linha de comando.

A principal conclusão diz respeito ao momento do registro. Se as afirmações forem registradas antes da crítica, os recuos indevidos na revisão de patches quase desaparecem, e os relatórios finais que já haviam passado pela verificação permanecem intactos mesmo sob pressão equivocada. Quando essa mesma anotação é escrita depois de ler a reclamação, o ganho praticamente some. Ou seja, o que importa não é o checklist em si, mas o fato de ele ter sido criado antes da pressão social.

Codificação, economia de tokens e trabalho sem crítica

Na codificação em múltiplas etapas, as anotações feitas antes da resposta reduzem significativamente as edições desnecessárias de arquivos após reclamações equivocadas. Aqui há um problema prático: um diff supérfluo no repositório custa tempo ao revisor e pode quebrar código funcional.

O método adiciona tokens, mas o autor propõe um limitador. O registro só é feito quando o próprio agente não tem certeza do resultado. Nessa configuração, o consumo de tokens é menor, e mais bugs reais são corrigidos do que na variante básica. Ou seja, a economia não compromete a capacidade de aceitar críticas justas.

O efeito não se limita a diálogos. Em tarefas sem feedback do usuário, basta listar as principais afirmações do rascunho e revisar novamente a mais frágil antes da entrega. Isso melhora tanto a precisão das respostas quanto a avaliação de confiança. O resultado se repetiu em todos os modelos testados.

O que já pode ser implementado em um agente

O método não exige fine-tuning nem acesso aos pesos do modelo, por isso pode ser montado no nível do prompt e da orquestração:

• Antes de cada entrega do trabalho, o agente salva uma lista oculta de afirmações, verificações e níveis de confiança. O usuário não a vê.
• O agente só lê a resposta do usuário depois que a lista foi salva.
• Diante de uma objeção, o agente primeiro consulta a lista e revisa apenas os pontos frágeis ou contestados pela primeira vez.
• O registro é ativado em casos de baixa confiança, para não inflar o custo em tokens.
• Para tarefas autônomas, é útil uma revisão final da afirmação mais frágil do rascunho.

Para equipes que constroem agentes de código e de análise, trata-se de uma forma barata de reduzir a bajulação sem tirar do agente a capacidade de se corrigir. O código e os materiais do projeto foram publicados na página thinking-in-bets.github.io.