Erro, supervisão humana e busca externa: os 3 padrões que evitam que um agente saia do controle

Um agente que planeja bem e se lembra do que já aconteceu ainda pode dar problema. Por exemplo, ele chama uma API que cai no meio da execução; toma sozinho uma decisão errada; ou responde com uma informação que era verdadeira há seis meses, mas já não é.

Nos posts anteriores, resumindo o trabalho de Antonio Gulli, vimos como um agente organiza o raciocínio e se lembra e aprende. Nenhum desses padrões, porém, resolve o que fazer quando algo dá errado, quando a decisão é grande demais para o agente tomar sozinho, ou quando a resposta certa depende de uma informação que mudou depois do treinamento do modelo. É isso que o terceiro grupo do mapa de padrões agênticos resolve.

Por que isso importa agora?

Um protótipo tolera erros. Um sistema em produção não. A diferença entre os dois não está em “o agente é mais inteligente”, e sim em como ele se comporta quando algo sai do previsto: ele trava, insiste sem parar ou “desliga” silenciosamente. Os três padrões deste grupo respondem, cada um, a uma pergunta específica: o que fazer quando falha, quem decide quando a aposta é alta, e de onde vem a informação quando o conhecimento do modelo já não é suficiente.

#12 Exception handling and recovery (tratamento de exceções e recuperação): o agente sabe se levantar sozinho

Todo sistema falha em algum momento. Uma API externa fica fora do ar, um serviço demora demais para responder, um resultado vem em um formato inesperado. A pergunta é: o que o agente faz quando isso acontece?

O padrão prevê três camadas de resposta, em ordem crescente de gravidade:

Retry with backoff (nova tentativa com espera)

Retry (nova tentativa) é simplesmente tentar novamente quando algo falha. Se uma chamada à API der erro, em vez de desistir na primeira falha, o agente tenta novamente. Já o backoff (espera) é a parte que evita um problema comum: se você tentar de novo imediatamente, e de novo, e de novo, sem pausa, pode sobrecarregar ainda mais um serviço que já está com dificuldade (ou tomar um bloqueio por excesso de requisições). Backoff significa esperar um tempo entre cada tentativa, e esse tempo aumenta a cada falha.

Um exemplo concreto, em números:

• Tentativa 1 falha. Espera 1 segundo.
• Tentativa 2 falha. Espera 2 segundos.
• Tentativa 3 falha. Espera 4 segundos.
• Tentativa 4 falha. O agente desiste desse caminho e passa para o fallback (ou escala para um humano).

Cada espera é o dobro da anterior. É por isso que costuma-se chamar “exponential backoff” (espera exponencial). 

A ideia de fundo é simples: um erro passageiro (a API caiu por 3 segundos) merece uma nova chance, mas com um intervalo entre as tentativas, não uma martelada imediata e repetida.

Fallback (recuo)

Fallback é o plano B do agente quando o plano A (a tentativa principal, mesmo com retry) continua falhando. A ideia é que, se o caminho preferido não estiver disponível, em vez de travar ou mostrar um erro ao usuário, o agente muda para um caminho alternativo que ainda entregue algum valor, mesmo que não seja o ideal.

Alguns exemplos concretos, do mais simples ao mais elaborado:

• Cache de resposta anterior. A API de cotação de frete caiu. Em vez de falhar, o agente usa o último valor calculado com sucesso (de alguns minutos atrás), avisando que pode estar levemente desatualizado.
• Fonte de dados secundária. O agente tenta buscar informações no sistema principal, que está fora do ar, e recorre a uma base secundária ou a um provedor alternativo com os mesmos dados, mesmo que seja mais lento ou menos completo.
• Modelo mais simples. O agente tenta usar um modelo de linguagem mais avançado (e mais caro ou mais lento) para gerar uma resposta. Se esse serviço estiver indisponível, ele cai para um modelo mais simples e rápido, que resolve a tarefa de forma mais básica, mas ainda assim funciona.
• Resposta genérica, mas honesta. Nenhum dos caminhos acima funciona. O fallback final é uma resposta padrão, algo como “não consegui buscar essa informação agora, tente novamente em alguns minutos”, em vez do sistema simplesmente travar ou devolver um erro técnico para quem não é dev.

O ponto central do fallback é degradar graciosamente. O agente entrega menos do que o ideal, mas não quebra por completo. Só quando nem o plano A nem o plano B funcionam é que entra a terceira camada, a escalação para um humano.

Escalar para o humano

A escalação para o humano ocorre quando nem a tentativa original, nem o retry, nem o fallback resolvem o problema. Nesse ponto, o agente para de tentar sozinho e passa a bola para um humano, em vez de continuar insistindo indefinidamente ou, pior, seguir em frente com um resultado ruim.

Na prática, escalação envolve algumas decisões de design:

1. Quando escalar. Normalmente depois de um número definido de tentativas falhas (por exemplo, 3 retries mais o fallback, todos sem sucesso), ou quando o tipo de erro indica que insistir não vai adiantar (um erro de autenticação, por exemplo, não se resolve tentando de novo).
2. Para quem escalar. Pode ser uma fila de suporte, um canal de Slack de operações ou uma notificação direta para a pessoa responsável por aquele fluxo. O importante é que exista um destino claro, não um erro que só fica registrado num log que ninguém consulta.
3. Com que informação. Uma boa escalação não diz só “falhou”. Ela leva junto o contexto: o que o agente estava tentando fazer, quais tentativas já foram feitas, incluindo o fallback, e qual foi o erro exato. Isso poupa a pessoa de ter que investigar do zero.
4. O que o usuário final vê. Enquanto a escalação acontece nos bastidores, quem está do outro lado (o cliente, por exemplo) geralmente recebe uma mensagem transparente, algo como “não consegui resolver isso automaticamente, um atendente vai assumir daqui”, em vez de silêncio ou um erro técnico.

Um jeito de enxergar a diferença entre os três níveis: 

• Retry with backoff: tenta de novo, pois o problema pode ser passageiro. 
• Fallback: não deu, mas ainda dá pra entregar algo. 
• Escalar para o humano: isso passou do que o agente deveria decidir sozinho; chame alguém. É a última rede de segurança antes do sistema falhar de forma visível para quem depende dele.

  

  Quando algo falha, o agente pode seguir três camadas de resposta: tentar novamente com espera, acionar um fallback e, se necessário, escalar o caso para um humano.

#13 Human in the loop (humano no circuito): quando a decisão não é do agente

Human in the loop é o nome do padrão em que uma pessoa revisa ou aprova uma ação antes dela ser executada, sempre que o risco ou o custo do erro for alto demais para deixar apenas com o agente.

O ponto central é definir o limiar (threshold) adequado. Nem toda ação precisa de aprovação humana. Afinal, se precisasse, o agente seria inútil. A definição de qual ação passa por revisão depende do impacto:

• Um agente de suporte que sugere uma resposta pode enviar diretamente se a confiança for alta e o tema for trivial.
• O mesmo agente, diante de um pedido de reembolso acima de um valor definido, pausa e aguarda a aprovação de um humano antes de efetuar o reembolso.

Isso exige registrar, para cada decisão automatizada, se ela foi revisada por alguém e por quem, o que também vira uma trilha de auditoria quando algo precisa ser investigado depois.

#14 Knowledge retrieval (recuperação de conhecimento): não confie só no que o modelo aprendeu no treinamento

O conhecimento de um modelo de linguagem tem uma data de corte. Depois disso, ele simplesmente não sabe o que mudou, seja uma política interna da empresa, um preço ou uma versão do produto.

RAG (Retrieval-Augmented Generation, ou geração aumentada por recuperação), que já apareceu no nosso artigo sobre infraestrutura de IA, é o mecanismo que resolve isso neste contexto: antes de responder, o agente busca a informação mais atual em uma base externa (um banco vetorial, uma base de documentos, um sistema interno) e monta a resposta com base no que encontrou, não apenas no que já sabia.

Um exemplo prático: um agente de suporte responde a uma pergunta sobre a política de reembolso da empresa. Sem RAG, ele responde com base no que aprendeu durante o treinamento, o que pode estar desatualizado. Com RAG, ele busca o documento de política vigente antes de responder, garantindo que a informação é a que vale hoje, não a de seis meses atrás.

Como os três se conectam

Um agente que sabe se recuperar de uma falha, sabe quando parar e chamar um humano, e busca informação atualizada em vez de confiar cegamente no que aprendeu, é a diferença entre um protótipo interessante numa demonstração e um sistema em que você confiaria para lidar com um cliente real.

O que vem a seguir

Erro tratado, decisão revisada e informação atualizada resolvem a questão da confiabilidade do agente em uma ação isolada. O último grupo da série mostra o que falta para colocar isso em produção de verdade: proteção contra respostas problemáticas, monitoramento contínuo, controle de custo e de velocidade, e o que fazer quando várias tarefas competem pela atenção ao mesmo tempo.

Pronto pra dar o próximo passo?

Dê uma olhada nos treinamentos sobre inteligência artificial da K21

• Product AI: para aprender a gerir a criação e evolução de produtos com a IA.
• Dominando o Claude
• Inteligência Artificial na Prática: criando um produto do zero a produção em menos de 3 dias.
• Design Thinking + IA

Veja outros artigos dessa série

1. IA agêntica tem gramática própria: os 4 grupos de padrões que você precisa conhecer
2. Orquestração e raciocínio: os 7 padrões que controlam o fluxo de um agente
3. Memória e aprendizado: os 4 padrões que fazem um agente parar de começar do zero
4. Escala e responsabilidade: os 7 padrões que fecham a série [publicação em breve]