Gauntlet Loop: guia para agentes autônomos

Agentes autônomos conseguem planejar, usar ferramentas e executar várias etapas sem alguém conduzindo cada movimento. O problema aparece quando a tarefa exige precisão: o resultado pode parecer pronto, mas conter lacunas, decisões frágeis ou código que nunca foi realmente testado. O ecossistema de agentes de IA cresce justamente porque autonomia exige mais do que uma boa resposta inicial.

O Gauntlet Loop propõe um ciclo simples de entender: definir um objetivo, dividir o trabalho, construir, avaliar com independência e refinar. A ideia não é fazer o modelo falar mais. É criar condições para que ele encontre problemas no próprio resultado antes de entregá-lo.

Neste guia, você vai ver como organizar os papéis de orquestrador, builders e críticos, escolher critérios verificáveis, controlar iterações e proteger ferramentas. Também vamos separar o que realmente melhora a confiabilidade daquilo que apenas adiciona complexidade ao sistema.

O Gauntlet Loop é um padrão para melhorar resultados de agentes autônomos por meio de ciclos sucessivos de construção e crítica. Um agente líder recebe o objetivo, divide o problema, delega partes, consolida o trabalho e envia cada resultado para uma avaliação independente. Se o resultado ainda não atinge a referência, começa outra rodada.

A proposta ganhou visibilidade com o projeto Claude of Duty, no qual um agente foi orientado a criar um jogo em Three.js comparável visualmente a um jogo comercial conhecido. O projeto publicou o prompt e mais de 55 mil linhas de código, segundo a descrição do método no Something Big e no repositório do Claude of Duty. O número não prova qualidade sozinho, mas mostra a escala que um loop pode alcançar quando existe um ambiente capaz de editar arquivos, executar código e inspecionar resultados.

A sequência pode ser resumida assim:

A diferença para uma cadeia de prompts é a presença de avaliação e retorno. Em uma cadeia comum, a saída de um prompt alimenta o próximo. Isso pode organizar o fluxo, mas não garante que alguém tenha comparado o resultado com uma referência. Já um chatbot costuma responder à solicitação atual. Um agente autônomo opera sobre um objetivo, toma decisões, chama ferramentas e altera o estado de um ambiente.

Segundo a descrição original, o crítico deve comparar diretamente o artefato com uma barra concreta, identificar a maior lacuna e devolver esse diagnóstico ao builder, como explica o autor do método. Essa comparação pode usar imagens, testes, métricas, exemplos de referência ou regras de negócio. “Faça algo incrível” não é uma avaliação. Um teste que precisa passar, sim.

O ponto mais interessante está na independência. O builder conhece as escolhas que fez e tende a justificar o próprio trabalho. O crítico recebe o objetivo, a barra e o artefato final, mas não precisa herdar toda a história da construção. Assim, pode apontar um erro que o agente original normalizou. Você confiaria em um desenvolvedor aprovando sozinho o código que acabou de escrever?

O Gauntlet Loop não exige vários modelos diferentes. Um mesmo modelo pode ocupar papéis distintos em chamadas separadas. Também não exige uma arquitetura específica. O essencial é separar produção, julgamento e decisão de continuidade, mantendo evidências suficientes para investigar cada rodada.

A arquitetura combina quatro funções: um Orchestrator decide o plano, Builders executam partes do trabalho, Critics avaliam os resultados e um Loop Controller controla o próximo passo. Essa divisão é útil quando o problema tem subtarefas que surgem durante a execução e quando a qualidade pode ser verificada por testes, referências ou critérios claros.

A estrutura se aproxima de dois padrões descritos pela Anthropic em Building Effective AI Agents. No padrão orchestrator-workers, um modelo central decompõe uma tarefa, delega atividades a workers e sintetiza as respostas. No padrão evaluator-optimizer, uma chamada produz o resultado e outra fornece avaliação e feedback em um ciclo.

O Orchestrator transforma uma solicitação ampla em unidades de trabalho. Ele decide o que pode ser paralelizado, quais dependências existem e qual especialista faz sentido. Em um projeto de análise de dados, pode separar ingestão, validação, exploração, modelagem e apresentação. Em software, pode distribuir mudanças por módulos, testes, documentação e segurança.

Os Builders, também chamados de workers, produzem artefatos concretos. Um worker pode escrever uma função, criar uma consulta SQL, montar um painel ou preparar uma análise. Cada tarefa precisa receber contexto suficiente, mas não necessariamente o histórico completo do projeto. Contexto demais aumenta ruído e custo; contexto de menos produz decisões incompatíveis.

Os Critics ou evaluators não devem avaliar apenas o texto “terminei a tarefa”. Eles precisam acessar o código executável, o relatório, os gráficos, os logs, os testes ou o estado alterado. A crítica deve responder três perguntas: o resultado atende ao objetivo, qual é a maior falha e qual mudança reduziria essa falha na próxima rodada?

O Loop Controller transforma a crítica em decisão operacional. Ele registra o score, verifica critérios obrigatórios, calcula orçamento restante e escolhe entre corrigir, repetir, pedir ajuda humana ou encerrar. Sem esse componente, o sistema tende a confundir atividade com progresso. Mais chamadas de modelo não significam necessariamente um produto melhor.

A Anthropic recomenda o padrão orchestrator-workers para tarefas complexas cuja decomposição não pode ser prevista antes da execução. A mesma referência cita mudanças em vários arquivos e buscas que combinam fontes como exemplos adequados, na documentação oficial. Quando o fluxo é curto e previsível, um único agente com ferramentas costuma ser mais simples, barato e fácil de depurar.

A decisão não deve partir da quantidade de agentes disponíveis. Use múltiplos workers quando as partes forem relativamente independentes, exigirem especialidades diferentes ou puderem ser executadas em paralelo. Evite-os quando todos dependem do mesmo contexto, quando o problema é pequeno ou quando a comunicação entre agentes custa mais do que o trabalho.

Um loop melhora um resultado apenas quando “melhor” pode ser observado. Comece traduzindo o objetivo em critérios de correção, completude, cobertura de requisitos, segurança, consistência e adequação ao contexto. Depois, associe cada critério a uma evidência: teste, regra, métrica, comparação, inspeção especializada ou aprovação humana.

A Anthropic classifica os graders em três grupos: baseados em código, baseados em modelo e humanos. Graders de código são rápidos, baratos, objetivos e reproduzíveis. Graders baseados em modelo lidam melhor com linguagem aberta e nuances. Avaliadores humanos oferecem julgamento especializado, mas custam mais tempo e dinheiro.

Para um agente que desenvolve software, correção pode significar testes unitários passando, tipos válidos, lint sem erros e ausência de regressões. Completude pode exigir que todos os requisitos tenham uma implementação correspondente. Segurança pode incluir análise estática, checagem de dependências, limites de acesso e confirmação antes de executar comandos destrutivos.

Para uma análise de dados, o critério muda. Você pode verificar se as fontes foram registradas, se as transformações são reproduzíveis, se os filtros estão documentados e se as conclusões são compatíveis com os dados. Um crítico que só avalia a prosa pode aprovar um relatório elegante com uma métrica calculada sobre a população errada.

Em tarefas abertas, uma rubrica ajuda. Ela pode atribuir notas para precisão, cobertura, clareza, qualidade das fontes e adequação ao público. Mas uma nota única esconde problemas. Prefira critérios separados, pesos explícitos e falhas bloqueadoras. Um relatório não deve passar porque a clareza compensou uma afirmação sem evidência.

A avaliação também precisa considerar o caminho, não apenas o resultado. Um agente pode chegar à resposta correta usando uma ferramenta proibida, expor dados sensíveis ou alterar um ambiente de produção. Por isso, registre chamadas de ferramentas, parâmetros, número de turnos, uso de tokens, mudanças no estado e justificativas relevantes.

Segundo a Anthropic, avaliações de agentes podem envolver múltiplos turnos, ferramentas e alterações persistentes no ambiente. O artigo diferencia capability evals, que medem o que o agente consegue fazer, de regression evals, que verificam se capacidades antigas continuam funcionando. A suíte de regressão deve buscar uma taxa de aprovação próxima de 100%, conforme a explicação técnica.

Use testes determinísticos sempre que puder. Eles são excelentes para formatos, valores, permissões, arquivos, contratos de API e comportamento esperado. Use um modelo avaliador para comparar alternativas, detectar lacunas ou julgar linguagem. Use pessoas para calibrar a rubrica, revisar casos ambíguos e avaliar decisões com impacto real. Uma combinação costuma ser mais confiável do que qualquer juiz isolado.

Outro cuidado é a ambiguidade da tarefa. Se o teste espera um arquivo em um caminho não informado, o agente pode falhar por causa da especificação. A avaliação precisa medir a capacidade do sistema, não uma armadilha acidental. Antes de aumentar o número de iterações, verifique se objetivo, dados, restrições e critérios estão claros.

Uma implementação prática começa com um contrato de tarefa: objetivo, restrições, entradas, saída esperada, ferramentas permitidas e critérios de parada. O Orchestrator transforma esse contrato em subtarefas. Workers executam em ambientes controlados. Critics avaliam evidências. O controller decide se corrige, repete, escala para uma pessoa ou encerra.

Imagine um agente responsável por construir um pipeline que recebe arquivos CSV, valida dados, calcula indicadores e publica um relatório. Na primeira rodada, o Orchestrator separa leitura, tratamento de valores ausentes, validação de tipos, cálculo das métricas e geração dos gráficos. Workers trabalham em partes independentes e salvam código, testes e decisões em um diretório versionado.

A primeira versão não deve ser considerada pronta porque o script executou uma vez. O sistema precisa rodar um conjunto de dados conhecido, casos com colunas ausentes, valores duplicados e formatos inesperados. Um critic de código revisa testes e estrutura. Outro verifica as métricas contra resultados de referência. Um terceiro avalia se o relatório explica limitações e fontes.

O feedback deve ser acionável. “Melhore a qualidade” não orienta a próxima rodada. “A métrica de retenção usa a data de cadastro como denominador, mas o requisito pede usuários ativos no início do período” aponta um defeito que o builder consegue corrigir. O controller registra essa falha, vincula-a ao requisito e exige um novo teste.

Mantenha pelo menos cinco tipos de estado: objetivo original, plano atual, artefatos, evidências e histórico de decisões. O histórico precisa mostrar o que mudou, quem avaliou, qual foi o score antes e depois, quais testes passaram e por que o loop continuou. Sem essa trilha, a depuração vira uma reconstrução manual de conversas longas.

A implementação pode usar uma máquina de estados simples:

Não limite a segurança ao prompt. O guia prático da OpenAI para agentes recomenda combinar guardrails com autenticação, autorização, controles de acesso e práticas tradicionais de segurança. Um agente que escreve código pode ter permissão para alterar uma branch de teste, mas não para publicar em produção sem aprovação.

Handoffs também ajudam a organizar responsabilidades. Um agente de triagem pode transferir o caso para um especialista, levando o estado recente da conversa. Em um loop, isso permite encaminhar uma falha de segurança para revisão especializada ou entregar um resultado aprovado ao agente responsável pela publicação. O handoff deve ter contrato claro, escopo limitado e condição de retorno.

Para controlar contexto, não passe todo o histórico em toda chamada. Resuma decisões estáveis, mantenha evidências em arquivos ou banco de dados e envie ao critic apenas o artefato relevante, a rubrica e os testes. O crítico precisa de independência, não de amnésia. Ele deve saber o que julgar sem receber a narrativa que tenta defender o resultado.

Monitore custo e latência por tarefa, rodada, worker e critic. Registre tokens, chamadas de ferramenta, tempo de execução, falhas e mudanças de score. Assim, você descobre se a quarta rodada realmente melhora o artefato ou apenas repete pequenas alterações. Que tipo de ganho justificaria dobrar o custo? Defina essa resposta antes de colocar o sistema para rodar.

O maior risco é confundir persistência com progresso. Um loop pode repetir a mesma correção, alternar entre duas soluções ou produzir mudanças cada vez menores. Por isso, estabeleça limite de iterações, orçamento, timeout, score mínimo, número máximo de falhas e condições explícitas de interrupção antes da primeira execução.

A avaliação também pode estar errada. Um critic baseado em modelo pode preferir uma resposta convincente, mas incorreta. Pode reproduzir o viés do builder, ignorar requisitos ou dar nota alta a uma saída que aprendeu a agradar à rubrica. A Anthropic lista a não determinismo e a necessidade de calibração humana entre as limitações dos graders baseados em modelo.

Existe ainda o problema da falsa sensação de qualidade. Vários críticos podem concordar porque receberam o mesmo contexto, usam a mesma referência ruim ou compartilham o mesmo erro factual. Independência exige mais do que nomes diferentes. Varie instruções, evidências, fontes e, quando possível, modelos. Compare o resultado com testes externos e amostras revisadas por especialistas.

Conflitos entre agentes são normais. Um worker pode priorizar desempenho, outro segurança e outro prazo. O Orchestrator precisa resolver prioridades com regras explícitas. Requisitos bloqueadores devem vencer preferências. Um ganho de latência não pode justificar a remoção de uma validação de privacidade sem autorização consciente.

Erros também se propagam. Um plano equivocado gera subtarefas equivocadas. Um dado contaminado alimenta análise, gráfico e relatório. Um resumo incorreto do estado leva todos os workers a tomar decisões ruins. Faça validações nas fronteiras: entrada, handoff, consolidação e publicação. Não espere que o critic final descubra toda falha acumulada.

Ferramentas ampliam o impacto dos erros. Ler um arquivo local é diferente de apagar registros, enviar mensagens, alterar permissões ou executar uma transação. Aplique menor privilégio, ambientes de sandbox, credenciais temporárias, allowlists e confirmação humana para ações irreversíveis. Guardrails baseados em regras e modelos devem funcionar como camadas, não como substitutos de controle de acesso.

Use checkpoints depois de etapas relevantes. Salve o estado antes de uma migração, da publicação de um dashboard ou do envio de uma comunicação externa. Se uma rodada piorar o artefato, faça rollback para a última versão aprovada. O loop deve conseguir falhar de forma recuperável.

A aprovação humana continua necessária em decisões médicas, jurídicas, financeiras, trabalhistas e de segurança. Também é necessária quando a saída representa a empresa, altera dados de clientes ou cria compromissos difíceis de desfazer. Nesses casos, o agente pode preparar opções e evidências, mas a responsabilidade não deve desaparecer atrás de um score automático.

Uma boa política de parada combina quatro sinais: critério de qualidade atingido, nenhuma falha bloqueadora aberta, orçamento ainda aceitável e risco compatível com a autonomia concedida. Se o score não melhora por duas rodadas, interrompa e peça revisão da decomposição ou da própria rubrica. Talvez o problema não seja a execução. Talvez a barra esteja errada.

O Gauntlet Loop vale a pena quando a tarefa tem várias etapas, alto custo de erro, critérios verificáveis e espaço real para refinamento. Ele é especialmente útil quando partes do trabalho podem ser paralelizadas e quando o artefato pode ser inspecionado diretamente. Para uma pergunta simples ou uma transformação determinística, a arquitetura extra costuma atrapalhar.

Use um único agente com ferramentas para consultar uma base, formatar um documento, executar uma rotina conhecida ou responder uma solicitação com baixo risco. O loop adiciona chamadas, estado, observabilidade e coordenação. Se não existe uma diferença mensurável entre a primeira e a segunda versão, não há motivo para inserir um crítico.

Considere o padrão para desenvolver funcionalidades em bases grandes, analisar muitas fontes, revisar código sensível, criar relatórios que exigem cobertura ou operar fluxos com várias dependências. A combinação de workers e critics pode reduzir pontos cegos, desde que o ambiente permita testes e o custo seja proporcional ao benefício.

Um bom sinal é a existência de uma referência externa. Pode ser uma suíte de testes, um resultado esperado, um conjunto de exemplos, uma política, uma métrica de negócio ou um especialista capaz de descrever o que está errado. Sem referência, o loop pode apenas otimizar para preferências internas do próprio sistema.

A complexidade não compensa quando os agentes compartilham o mesmo contexto, os critérios são vagos, o problema muda a cada rodada ou a latência é mais importante do que a qualidade marginal. Nesse caso, comece com um fluxo simples, registre falhas reais e só depois adicione decomposição e avaliação onde houver evidência de necessidade.

O Gauntlet Loop é melhor entendido como um padrão de execução e avaliação. Ele descreve uma dinâmica de dividir, construir, julgar e repetir, mas não impõe biblioteca, modelo ou provedor. Você pode implementá-lo em um script próprio, em um framework de agentes ou em ambientes como Claude Code e Codex, desde que existam ferramentas e controle de estado.

Sistema multiagente descreve vários agentes que colaboram, delegam ou disputam tarefas. O Gauntlet Loop descreve o ciclo de melhoria com avaliação independente. Um loop pode usar um único modelo em papéis separados. Um sistema multiagente pode executar uma tarefa uma única vez, sem crítica ou refinamento. Os conceitos se combinam, mas não são sinônimos.

Não existe número universal. A quantidade deve depender do ganho observado, do risco, do orçamento e da latência aceitável. A proposta original recomenda não fixar arbitrariamente três rodadas, mas parar quando o resultado estiver pronto, quando as melhorias forem pequenas ou quando o orçamento terminar, segundo o guia do Gauntlet Loop. Na prática, registre scores por rodada e defina um limite máximo.

Combine limite de iterações, timeout, orçamento de tokens, limite de chamadas, detecção de mudanças repetidas e condição de progresso mínimo. Se o score não melhorar ou a mesma falha reaparecer, interrompa. Também vale exigir que cada nova rodada apresente uma evidência diferente, como um teste novo, uma correção verificável ou uma comparação mais adequada.

Não em tarefas de alto risco. Um critic automático ajuda a encontrar lacunas, mas pode compartilhar vieses e erros do sistema. A Anthropic recomenda combinar graders de código, modelo e avaliação humana conforme o caso. Testes determinísticos devem validar o que for objetivo, enquanto especialistas calibram rubricas e revisam decisões ambíguas, como detalhado no guia de evals.

O builder cria ou altera uma parte do artefato. O orchestrator divide o objetivo, coordena workers e consolida resultados. O critic avalia o artefato contra critérios ou referências e aponta a maior lacuna. Separar esses papéis reduz a chance de o agente responsável pela construção aprovar o próprio trabalho sem uma verificação independente.

O padrão pode funcionar em qualquer ambiente que permita ao agente acessar ferramentas, modificar artefatos, executar verificações e controlar iterações. O texto original destaca Claude Code e Codex, mas a ideia não depende desses produtos. No Cursor ou em outra ferramenta, você precisará implementar ou configurar decomposição, críticos, armazenamento de estado e limites de execução.

Use avaliação humana quando há ambiguidade relevante, impacto alto, risco reputacional ou ação irreversível. Pessoas também são necessárias para calibrar graders baseados em modelo e revisar casos em que múltiplas respostas parecem válidas. O crítico automático é ótimo para escala e repetição. Ele não deve ser tratado como autoridade final em decisões que exigem responsabilidade.

Autonomia não garante qualidade. Um agente pode planejar bem e executar a tarefa errada, ou produzir um resultado convincente sem evidências suficientes. O Gauntlet Loop ajuda porque transforma a execução em um ciclo observável de decomposição, construção, crítica e refinamento. O ganho vem dos critérios e das evidências, não da quantidade de agentes.

Comece pequeno: escolha uma tarefa com saída verificável, registre o primeiro resultado e defina o que um crítico precisa encontrar. Depois adicione testes, logs, checkpoints, limites e revisão humana proporcional ao risco. Se a arquitetura não melhora uma métrica relevante, remova a complexidade.

Para continuar explorando agentes, ferramentas e sistemas multiagentes, leia o guia do Data Hackers sobre frameworks de agentes de IA. E, para receber análises sobre dados, inteligência artificial e engenharia diretamente no seu e-mail, inscreva-se na newsletter do Data Hackers.

A meta não é manter o loop rodando para sempre. É saber por que ele começou, como o resultado melhorou e em que momento uma pessoa, um teste ou uma regra deve assumir o controle.