Aconteceu. Um agente nosso, em produção, travou num ciclo infinito e ficou respondendo a mesma coisa pra um lead por 47 minutos até ele sair da conversa.
Não foi bonito. Mas foi muito útil.
Esse post é sobre o que aconteceu, por que aconteceu, e o que mudamos depois.
O cenário
O Pixe é um agente de qualificação que a gente usa internamente. Ele recebe leads via WhatsApp, entende o contexto, faz perguntas de qualificação e agenda uma conversa com a gente quando faz sentido.
Funciona bem. Funciona bem na maioria dos casos.
Nesse dia específico, o lead mandou uma pergunta ambígua sobre preço. Algo do tipo: "mas é caro?" — sem contexto anterior suficiente pra o agente saber o que exatamente estava sendo comparado.
O Pixe pediu mais contexto. O lead deu uma resposta igualmente vaga. O Pixe pediu mais contexto de novo. E aí começou o loop.
Quarenta e sete minutos de dois caras que não se entendiam — um humano frustrado e uma máquina incansável.
Por que loops acontecem
Um agente entra em loop quando não tem critério de saída pra uma situação que não foi prevista no design.
É simples assim.
No nosso caso, o fluxo tinha uma lógica do tipo: "se a resposta não for suficiente pra avançar, peça mais informação". Funciona perfeitamente quando o lead está disposto a detalhar. Quebra quando o lead não sabe o que você quer, ou não quer dar esse trabalho.
O agente ficou preso entre dois estados: não tenho informação suficiente e não consigo obter informação suficiente. Sem uma terceira saída, ele repetiu o comportamento indefinidamente.
Isso tem nome em teoria de controle: é um sistema sem condição de escape. Em produção com humano do outro lado, é uma experiência horrível.
O que a gente não tinha feito
Três erros claros:
1. Sem limite de tentativas por etapa
A gente não definiu quantas vezes o agente podia pedir a mesma informação antes de mudar de estratégia. Dois é razoável. Três já é chato. Sete é demissão.
2. Sem fallback pra ambiguidade persistente
Quando o usuário não consegue responder de um jeito que o agente entende, o agente precisa ter uma saída digna. "Deixa eu te conectar com alguém do time" é uma saída digna. Perguntar de novo não é.
3. Sem monitoramento em tempo real
Esse loop durou 47 minutos porque ninguém estava olhando. A gente não tinha alerta configurado pra detectar conversas longas sem progresso. O lead saiu, a gente viu no log horas depois.
O que mudamos
Depois desse episódio, implementamos três coisas que agora são padrão em qualquer agente que a gente sobe:
Contador de tentativas por intenção
Cada vez que o agente tenta coletar uma informação específica, incrementa um contador. No segundo tentativa sem sucesso, muda a abordagem. Na terceira, escala pra humano ou encerra com graça.
tentativas_contexto_preco = 0
if resposta_ambigua:
tentativas_contexto_preco += 1
if tentativas_contexto_preco >= 2:
→ acionar fallback
else:
→ reformular pergunta
Não é código sofisticado. É só disciplina.
Fallback explícito pra ambiguidade
Agora o agente tem uma resposta específica pra quando ele detecta que não está conseguindo avançar: ele admite, oferece uma alternativa e passa o bastão.
Algo como: "Percebo que preciso de mais contexto pra te dar uma resposta boa aqui. Posso te conectar com o Raffa ou o Dudu diretamente — eles conseguem entender melhor o seu caso."
Isso não é fraqueza do agente. É design inteligente.
Alerta de conversa estagnada
Qualquer conversa que passa de 10 minutos sem mudança de estado dispara uma notificação pra gente. Simples, via webhook. Dez minutos é tempo suficiente pra intervir sem o lead desistir.
Desde que implementamos isso, interceptamos outras situações antes de virarem problema.
O que esse episódio ensinou sobre agentes
Agente bom não é agente que nunca erra. É agente que sabe quando não sabe, e tem um plano pra isso.
Muita gente projeta agentes pensando no caminho feliz: o usuário responde certinho, o agente coleta tudo, agenda tudo, perfeito. A vida real tem usuários que digitam "caro?" e esperam mágica.
O trabalho real de engenharia de agentes é desenhar os caminhos feios. O que acontece quando a resposta é ambígua? Quando o usuário some no meio? Quando ele responde uma coisa mas quer outra? Quando ele manda áudio em vez de texto?
Cada um desses casos precisa de uma saída definida. Se não tem saída definida, o agente improvisa — e improviso em loop é o pior cenário possível.
Sobre o lead
A gente não recuperou ele. Tentamos entrar em contato depois, explicamos o que aconteceu de forma honesta, mas ele já tinha seguido em frente.
Faz parte.
O que ficou foi um sistema melhor e uma régua mais clara de qualidade. Todo agente que a gente entrega hoje passa por um checklist que inclui explicitamente: quais são os estados de saída pra cada intenção? Quantas tentativas antes do fallback? Quem é notificado quando a conversa trava?
Se você está construindo agentes pra uso real, não deixa isso pra depois. Loop em produção com cliente do outro lado não é bug técnico — é experiência horrível que tem nome e CPF.
Esse tipo de falha é constrangedor de assumir publicamente. Mas é exatamente o tipo de coisa que a gente aprende mais do que com qualquer demo bonita funcionando perfeitamente numa apresentação.