Agente de IA em loop infinito: limites de passos, tempo e gasto

Agente de IA em loop infinito: limites de passos, tempo e gasto

Um agente de IA em loop infinito só é contido de verdade quando o limite fica fora do modelo: um contador de passos, um relógio e um teto de gasto, todos aplicados pelo código que executa o agente, mais uma regra para detectar repetição. Quando qualquer limite é atingido, o agente para, registra o estado e transfere o caso a uma pessoa, em vez de tentar mais uma vez. Pedir no prompt que o agente não repita ajuda, mas não substitui o freio.

Principais pontos

• O limite precisa ser imposto pelo sistema que roda o agente, não pela boa vontade do modelo.
• Três tetos trabalham juntos: número de passos, tempo total e orçamento de tokens ou chamadas. O primeiro que for atingido encerra a execução.
• Repetição se detecta comparando ações e resultados recentes, não apenas contando passos.
• Parar bem é parte do desenho: o agente entrega um resumo do que tentou e o caso vai para uma pessoa com contexto.
• Todo encerramento por limite deve ficar registrado, porque é o melhor sinal de que um fluxo precisa de ajuste.

Por que um agente de IA entra em loop infinito?

Um agente, na forma mais comum, funciona em ciclo: o modelo decide uma ação, uma ferramenta executa, o resultado volta ao modelo, que decide de novo. Esse ciclo só termina quando o modelo julga que acabou ou quando algo externo o interrompe. Se nada externo existe, o fim depende inteiramente do julgamento do modelo, e é aí que o problema nasce.

As causas mais frequentes são previsíveis:

• A ferramenta devolve um erro que o modelo não entende e ele tenta a mesma chamada de novo, com pequenas variações.
• O critério de conclusão é vago, então o agente nunca considera a tarefa pronta.
• A informação que o agente procura não existe, mas ele continua buscando em vez de admitir isso.
• O contexto cresce a cada volta e o agente esquece o que já tentou (veja janela de contexto em IA), repetindo caminhos já descartados.
• Duas partes do sistema, por exemplo um agente e uma automação, reagem uma à saída da outra sem fim.

A documentação da Anthropic sobre construção de agentes descreve que a execução costuma incluir condições de parada, como um número máximo de iterações, justamente para manter o controle. Isso é documentação oficial. O restante deste texto mistura essa base com boas práticas de implantação e algumas hipóteses de trabalho, que indicaremos quando for o caso.

Quais são os três tetos que todo agente precisa?

Um teto sozinho deixa brechas. Um limite de passos não protege contra uma única chamada lenta que trava por muito tempo. Um limite de tempo não protege contra passos rápidos que consomem muitos tokens. Por isso os três funcionam em conjunto.

Teto de passos

Defina o número máximo de voltas do ciclo para cada tipo de tarefa. O valor certo nasce do fluxo real: observe quantos passos uma execução saudável usa e fixe o teto com uma folga razoável acima disso, não muito acima. Um agente que responde uma dúvida simples não precisa da mesma folga de um que cruza três sistemas.

Teto de tempo

Defina um prazo total de execução e também um prazo por chamada de ferramenta. No atendimento por WhatsApp, o prazo total deve ser compatível com a paciência de quem espera a resposta. Se o cliente aguarda, o tempo é parte da experiência, não só da engenharia.

Teto de orçamento

O custo de um modelo de linguagem acompanha os tokens processados (entenda em o que são tokens em IA). Em um loop, cada volta reenvia contexto que só cresce, então o gasto sobe mais rápido do que o número de passos sugere. Defina um orçamento máximo por execução, medido em tokens ou em chamadas pagas, e um segundo orçamento por período (dia ou mês) para o agente como um todo. O segundo protege contra o caso em que cada execução respeita o limite, mas milhares delas acontecem sem controle.

O OWASP, na lista dos principais riscos para aplicações com LLM, trata o consumo sem limites como uma categoria de risco própria. Limitar recursos por execução e por período é uma das defesas básicas.

Como detectar repetição antes de bater no teto?

Os tetos são a rede de segurança. A detecção de repetição é o alarme que dispara antes, e economiza passos, tempo e dinheiro. A ideia é simples: o código que executa o agente guarda um histórico curto das últimas ações e compara.

Sinais práticos para monitorar:

• A mesma ferramenta chamada com os mesmos argumentos mais de uma vez em sequência curta.
• A mesma ferramenta com argumentos quase iguais, mudando apenas um detalhe irrelevante.
• O mesmo erro retornado repetidamente pela ferramenta.
• Alternância entre duas ações (A, B, A, B), um padrão típico de oscilação.
• Respostas do modelo muito parecidas entre voltas, sem informação nova.
• Ausência de progresso: o estado da tarefa (campos preenchidos, itens resolvidos) não muda após algumas voltas.

A última é a mais valiosa. Repetição de texto é fácil de medir, mas o que importa é se a tarefa avançou. Se o fluxo tem um estado explícito, por exemplo dados coletados do cliente, compare esse estado entre voltas. Sem mudança, o agente está girando.

O que fazer quando a repetição aparece? Há uma escada de respostas, da mais leve à mais firme:

• Na primeira repetição, injetar uma mensagem do sistema lembrando o que já foi tentado e pedindo uma abordagem diferente.
• Na segunda, remover ou desativar a ferramenta que está falhando para aquela execução.
• Na terceira, encerrar e transferir.

Esses números de tentativas são um ponto de partida de trabalho, uma hipótese a calibrar com os registros do piloto, não uma regra universal.

Como encerrar com handoff em vez de continuar tentando?

Parar é fácil. Parar bem exige desenho. Um agente que simplesmente some ou responde um erro genérico gera retrabalho e frustração. O encerramento correto tem quatro partes.

• Mensagem honesta a quem está esperando: o agente informa que não conseguiu concluir e que uma pessoa vai assumir, sem prometer prazos que o sistema não controla.
• Pacote de contexto para o humano: objetivo da tarefa, o que já foi coletado, o que foi tentado, qual limite foi atingido e qual foi o último erro.
• Destino claro: uma fila, um responsável ou um canal definido de antemão, com horário de atendimento considerado (veja atendimento fora do horário com IA).
• Ações pendentes seguras: nada que esteja pela metade pode ficar em estado inconsistente. Se o agente iniciou um cadastro ou um envio, o encerramento precisa concluir, desfazer ou sinalizar isso.

Esse último ponto merece atenção. Interromper no meio de uma sequência de ações com efeito externo, como criar um pedido e ainda não enviar a confirmação, pode deixar o sistema sem coerência. Ações com efeito devem ser idempotentes ou ter confirmação, para que repetir ou abortar não duplique nada. Para a lógica de validação de entradas e saídas, o texto sobre guardrails em agentes de IA detalha esse tipo de controle.

Se o agente toma decisões que afetam pessoas, o handoff também apoia o direito de revisão previsto na LGPD. O artigo sobre decisões automatizadas e o art. 20 da LGPD trata desse tema.

Passo a passo para implantar os limites

Um plano enxuto, na ordem em que costuma funcionar:

• Liste os fluxos do agente e, para cada um, descreva o que significa concluído e o que significa falhou.
• Observe execuções saudáveis e anote passos, tempo e tokens usados. Esse é o seu baseline.
• Fixe os três tetos por fluxo, com folga moderada acima do baseline.
• Implemente os tetos no código que executa o agente, nunca apenas no prompt.
• Adicione a detecção de repetição com a escada de respostas descrita acima.
• Defina o destino do handoff e o formato do pacote de contexto.
• Crie um orçamento por período para o agente inteiro, com alerta antes do corte.
• Teste de propósito: simule uma ferramenta que sempre falha, uma busca sem resultado e uma pergunta ambígua, e confirme que o agente para e transfere.
• Revise os encerramentos por limite toda semana no início, e depois com menos frequência.

Cenário ilustrativo

Imagine uma empresa de serviços que usa um agente no WhatsApp para consultar o status de um pedido. O sistema interno fica fora do ar por alguns minutos e a ferramenta de consulta passa a devolver erro. Sem limites, o agente tentaria a consulta sem parar, consumindo tokens a cada volta, enquanto o cliente espera. Com os limites, a segunda chamada idêntica falha e dispara o aviso de repetição. A terceira falha desativa a ferramenta para aquela conversa. O agente então diz ao cliente que não conseguiu consultar agora e que um atendente vai retornar, e abre um chamado com o número do pedido, o erro recebido e o horário. O custo ficou contido e a pessoa que assumiu não precisou perguntar tudo de novo. Este é um exemplo ilustrativo, não um resultado de cliente.

O que registrar para enxergar loops antes que custem caro?

Sem registro, o loop só aparece na fatura ou na reclamação. Cada execução deve deixar rastro estruturado: identificador da execução, fluxo, número de passos, tempo total, tokens consumidos, ferramentas chamadas, motivo do encerramento (concluído, limite de passos, limite de tempo, limite de orçamento, repetição, erro) e se houve handoff.

Com isso, algumas perguntas ficam respondíveis:

• Qual fluxo mais encerra por limite? Provavelmente o critério de conclusão ou uma ferramenta precisa de revisão.
• Qual ferramenta mais aparece antes de uma repetição? Talvez sua descrição ou seu retorno de erro estejam confusos. A Anthropic tem um guia útil sobre como escrever ferramentas melhores para agentes.
• O custo médio por execução está estável ou subindo?

Os registros também podem seguir convenções de observabilidade. A OpenTelemetry mantém convenções semânticas para IA generativa, o que ajuda a padronizar campos de uso de tokens e chamadas de modelo entre sistemas. Cuidado com dados pessoais nos logs: registre o necessário para auditar, mascare o restante e defina prazo de retenção, em linha com a LGPD.

Um detalhe de método: encerramentos por limite não são falhas a esconder. São o dado mais honesto sobre onde o agente ainda não é confiável. Se a equipe passa a ser cobrada por reduzir esse número, o risco é afrouxar os tetos para a métrica parecer boa. Para evitar esse desvio, vale ler sobre como medir um piloto de automação com IA.

Como esse controle entra no método de trabalho?

No método que seguimos, os limites de loop aparecem em cada etapa. Em mapear, descrevemos o processo atual e medimos o baseline de passos, tempo e esforço humano, porque sem ele o teto seria um palpite. Em limitar, definimos dados acessíveis, ações permitidas e os três tetos, além do critério de handoff. Em pilotar, rodamos um fluxo real com registro de decisões e uma métrica de sucesso combinada, e usamos os encerramentos por limite para calibrar. Em transferir, entregamos a operação com o painel de registros e a regra clara de quando expandir, ajustar ou parar.

Quando o agente atende em WhatsApp, o desenho do handoff precisa respeitar as regras do canal e do atendimento humano; o guia sobre como integrar IA no WhatsApp da empresa cobre essa base.

Perguntas frequentes

Quanto deve valer o limite de passos? Não existe um número universal. Meça execuções saudáveis do seu fluxo e fixe o teto com uma folga moderada acima delas. Depois ajuste com base nos encerramentos por limite que aparecerem no piloto.

Posso colocar o limite apenas no prompt? Não é suficiente. O modelo pode ignorar, esquecer ou interpretar mal uma instrução de parar, e o prompt não impede uma chamada travada nem o crescimento do custo. O limite confiável é o que o código de execução aplica, com o prompt apenas reforçando o comportamento desejado.

O que fazer quando o agente atinge o limite no meio de uma ação com efeito externo? Antes de qualquer outra coisa, o sistema deve deixar o estado consistente: concluir a ação, desfazê-la ou marcá-la claramente como pendente para o humano. Projetar as ações como idempotentes, ou com confirmação, reduz o risco de duplicar pedidos, envios ou cadastros.

Como evitar que o handoff vire um gargalo? Transfira só o que o agente realmente não consegue resolver e envie o pacote de contexto completo, para que a pessoa não recomece do zero. Acompanhe o volume de transferências por fluxo. Se um fluxo transfere demais, o ajuste costuma estar nas ferramentas, no critério de conclusão ou no escopo do agente, não no tamanho da equipe.

Fontes

• Anthropic: Building effective agents
• Anthropic: Writing effective tools for agents
• OWASP Top 10 for LLM Applications
• OpenTelemetry: semantic conventions for generative AI