Você provavelmente está medindo seu agente de IA errado (e como um grupo de comparação resolve isso)

A afirmação que ninguém sustenta

Todo produto de agente diz que deixa o modelo melhor. Quase nenhum prova. Não porque os agentes não melhorem — mas porque a medição está quebrada de um jeito sutil e específico.

Loops de estratégia são detectáveis sem LLM

Um loop de estratégia é a mesma classe de ação falhando repetidamente em alvos distintos — o agente editando três arquivos do mesmo jeito errado, ou repetindo a mesma correção que não funciona. Você não precisa de um modelo para perceber isso. Uma regra dura e auditável dá conta:

A mesma tentativa se repetiu pelo menos 3 vezes, em pelo menos 2 lugares diferentes, e a última delas deu errado.

Determinística, não manipulável. A classe vem de ferramenta + código de erro + mensagem normalizada; o alvo (arquivo/caminho) separa uma nova tentativa legítima de um loop de estratégia. É uma garantia anti-Goodhart: você não consegue afrouxar a regra para deixar seus números mais bonitos.

A armadilha: viés de seleção

Uma vez que você consegue detectar loops, o passo óbvio é intervir e medir. E a medição óbvia está errada: o detector só dispara em sessões difíceis, então "com intervenção" vs "sem intervenção" compara difícil contra fácil. Sua intervenção parece prejudicial. Você não lança nada — ou pior, remove um recurso que de fato ajudava.

Isso não se corrige depois, com estatística. Corrige-se na coleta.

A correção: um grupo de comparação cego

No instante da detecção — o único momento em que os dois grupos são comparáveis — atribua o loop a treated ou holdout:

• treated (tratado): intervir (apresentar uma provocação e deixar o agente se reorganizar).
• holdout (comparação): detectar, medir e ficar em silêncio. A intervenção existe, mas nunca é entregue. Avisar o agente já seria intervir, e colapsaria o experimento.

A atribuição é determinística — hash(run | assinatura) — porque a detecção pode rodar mais de uma vez ao longo de uma sessão; um sorteio aleatório colocaria o mesmo loop em grupos diferentes a cada rodada e apodreceria a amostra.

Julgue os dois grupos com a mesma régua

O grupo tratado tem um sinal natural de sucesso; o de comparação não tem nenhum. Comparar "o veredito da intervenção" com "o que quer que tenha acontecido na comparação" é comparar instrumentos diferentes. Então leia o resultado do próprio fluxo de eventos, nos dois grupos: ≥3 falhas da mesma classe após a detecção → recorreu; um sucesso com a mesma ferramenta em um alvo onde ela vinha falhando → quebrou o loop. Esse resultado comparável é a métrica. O ganho é a taxa de quebra no grupo tratado menos a taxa de quebra no grupo de comparação.

Por que não simplesmente perguntar a um LLM se ele está em loop?

Um LLM dá um palpite plausível, não uma regra; muda de resposta a cada rodada; não tem memória da semana passada; e rodá-lo a cada ação é absurdamente caro. Use regras determinísticas baratas para observar continuamente, e gaste o modelo só no momento raro e decisivo em que um loop real é confirmado.

O hook

Construímos isso sobre hooks do editor: um arquivo de configuração mais um script Node sem dependências. Fail-open (nunca bloqueia o editor), dormente sem token, e envia apenas nome da ação, alvo e resultado — nunca o seu código. Em um loop confirmado, ele injeta a provocação de volta na conversa.

O que aprendemos usando em nós mesmos

Chamadas repetidas de leitura/busca disparavam o detector — falsos positivos de navegação. Um loop de estratégia real exige ações executivas (edições, execuções, comandos), não o agente apenas olhando em volta. Então ferramentas somente-leitura deixaram de contar como tentativas. A coisa que mede a coisa pegou a si mesma.

Onde estamos

Estamos coletando dados agora e — em plena transparência — ainda não temos números de ganho. Vamos publicar taxas de loop e o ganho medido com o tamanho da amostra junto, nunca uma razão sem um n. Compartilhamos o método agora porque o desenho da medição é a parte que vale ser testada em público.