A ferramenta demorou. O agente tentou de novo.
O cliente pediu para remarcar terça para quinta.
O agente chamou a agenda. A resposta não voltou dentro do tempo esperado. Então ele repetiu a chamada e respondeu: “Pronto, ficou para quinta.”
Na agenda, terça continuou marcada e quinta apareceu duas vezes.
Parece um problema técnico. Para o cliente, é uma promessa quebrada. Para a operação, é trabalho de descobrir qual ação aconteceu, desfazer duplicidade, pedir desculpa e corrigir a integração.
Quando uma ferramenta falha, o agente não precisa improvisar melhor. Precisa saber qual estado ainda é verdadeiro, o que pode repetir e quando deve parar.
Resposta curta
Para recuperar uma falha de ferramenta sem criar outro erro:
- guarde a intenção e a autorização recebida;
- dê um identificador estável à tentativa;
- registre a chamada e o último estado confirmado;
- se a resposta sumir, verifique antes de repetir;
- repita automaticamente apenas ações seguras;
- não anuncie sucesso sem confirmação;
- quando o estado continuar incerto, passe para uma pessoa ou combine retorno com protocolo;
- depois, ligue a falha à correção e ao reteste.
O nome técnico pode ser idempotência, reconciliação ou tratamento de erro. No atendimento, a regra cabe numa frase: não faça duas vezes só porque você não viu a primeira terminar.
O agente não executa a ferramenta sozinho
A documentação de function calling da OpenAI separa o trabalho em etapas. O modelo pede uma chamada; a aplicação executa código; o resultado volta; só então o modelo prepara a resposta final.
Isso importa porque o texto do agente não prova que a ação aconteceu. Entre “vou cancelar” e “foi cancelado” existem aplicação, credencial, API, sistema responsável e resposta.
Uma operação minimamente auditável guarda pelo menos:
| Campo | Exemplo |
|---|---|
| intenção | remarcar uma reserva existente |
| autorização | cliente confirmou quinta às 15h |
| ferramenta | agenda responsável pelo horário |
| identificador | remarcacao-8472-20260722 |
| entrada | reserva original + novo horário |
| início da tentativa | 10:31:04 |
| resposta recebida | timeout / erro / sucesso |
| estado confirmado | terça ainda ativa; quinta desconhecida |
| mensagem enviada | “Estou verificando antes de confirmar.” |
| próxima ação | consultar pelo identificador e, se necessário, passar para humano |
Sem esse rastro, QA recebe apenas duas histórias: o agente diz que tentou e o cliente diz que deu errado. Ambas podem ser verdade.
Existem três falhas diferentes
“Deu erro” é uma classificação pequena demais.
1. Falha antes da execução
A chamada nem chegou ao sistema ou foi rejeitada antes de qualquer mudança.
Exemplos:
- argumento inválido;
- autenticação recusada;
- regra de negócio bloqueou;
- serviço indisponível antes de processar.
Aqui pode ser seguro corrigir a entrada ou tentar novamente, desde que o sistema deixe claro que nada aconteceu.
2. Falha depois da execução
A ação aconteceu, mas a resposta se perdeu.
Exemplos:
- a agenda criou a reserva e a rede caiu antes da confirmação;
- o CRM atualizou e a aplicação recebeu timeout;
- o cancelamento foi processado, mas o retorno chegou tarde.
Repetir sem verificar pode duplicar ou inverter a ação.
3. Estado desconhecido
A operação não consegue provar se aconteceu.
Esse é o caso mais perigoso. O agente não deveria escolher a versão mais conveniente. Precisa consultar o sistema responsável, procurar pelo identificador da tentativa ou entregar a investigação para uma pessoa.
| Estado conhecido | O que o agente pode dizer |
|---|---|
| não executado | “A ação não foi concluída. Vou tentar novamente.” |
| executado e verificado | “A ação foi concluída. Este é o protocolo.” |
| resultado desconhecido | “A tentativa não retornou confirmação. Vou verificar antes de repetir.” |
“Provavelmente foi” não é um estado operacional.
Repetir consulta é diferente de repetir ação
Consultar status costuma ter menos efeito colateral do que criar, cobrar, cancelar, enviar ou atualizar.
Separe as ferramentas em três grupos:
| Tipo | Exemplos | Regra de repetição |
|---|---|---|
| leitura | consultar pedido, saldo, horário ou cadastro | pode repetir com limite e intervalo |
| escrita reversível | atualizar observação, criar tarefa de revisão | repetir só com identificador e verificação |
| escrita sensível | cobrar, cancelar, reembolsar, reservar, disparar mensagem | não repetir cegamente; verificar ou chamar humano |
A classificação precisa considerar a operação, não apenas o verbo da API. “Atualizar” um campo de observação pode ser simples. “Atualizar” o endereço antes de uma entrega pode ter impacto grande.
Chave estável evita que uma tentativa vire duas ações
A Amazon Builders’ Library descreve por que retries ficam perigosos quando uma chamada tem efeito colateral. Se o cliente não sabe se a primeira tentativa funcionou, uma repetição pode criar um segundo recurso. APIs idempotentes usam um identificador do pedido para reconhecer que a repetição representa a mesma intenção.
Traduzindo para uma rotina de agente:
- gere a chave antes de executar;
- preserve a mesma chave ao repetir a mesma intenção;
- gere outra chave apenas quando o cliente realmente fizer um novo pedido;
- guarde a resposta ligada à chave;
- não deduza identidade apenas porque os argumentos parecem iguais.
Duas compras iguais podem ser duas intenções legítimas. Duas tentativas com a mesma chave são a mesma intenção repetida.
Se a ferramenta não aceita chave idempotente, crie uma camada de controle: registre a tentativa localmente e consulte o sistema antes de enviar de novo.
Registro de falha de ferramenta
Use o registro de falha de ferramenta do agente para revisar uma ocorrência real ou montar um teste antes do go-live.
Separe consulta, criação, mudança, cancelamento e envio. A recuperação não pode ampliar o pedido.
Ferramenta, entrada, horário, identificador, versão da regra e resposta recebida.
Não executado, executado, revertido ou desconhecido. Evidência vem do sistema responsável.
Mensagem precisa refletir o estado real e explicar prazo, protocolo e próximo passo.
A escolha depende do efeito colateral, da reversibilidade e da certeza disponível.
Dono, prazo, causa, alerta e bateria de reteste impedem a mesma falha de voltar maquiada.
Fluxo de recuperação
O cliente precisa de uma resposta útil durante a falha
A resposta não pode ser apenas “ocorreu um erro”. Também não pode fingir sucesso.
Uma mensagem útil contém:
- o que não foi confirmado;
- o que será verificado;
- se o cliente precisa fazer algo;
- quando haverá retorno;
- qual protocolo ou canal acompanha o caso.
Exemplo:
Tentei remarcar, mas a agenda não confirmou o resultado. Não vou repetir antes de verificar para evitar duas reservas. Registrei o pedido no protocolo 8472 e retorno por este WhatsApp até 11h30. Você não precisa enviar os dados de novo.
Se não existe capacidade de cumprir 11h30, não escreva 11h30. Prazo inventado não recupera integração. Só agenda o próximo recontato.
Monitorar disponibilidade não é detalhe de infraestrutura
A documentação do WhatsApp Flows trata taxa de erro, latência e disponibilidade do endpoint como sinais de saúde. Uma degradação pode levar o fluxo a ser limitado ou bloqueado.
A ferramenta específica pode mudar. A disciplina permanece:
- medir erro por ferramenta e ação;
- separar timeout de rejeição de negócio;
- alertar antes de o cliente descobrir em escala;
- acompanhar duração da falha;
- saber quais conversas foram afetadas;
- ter modo degradado para cada ação importante.
Modo degradado não significa manter toda função. Pode ser só parar de executar, coletar o pedido e criar uma fila humana com contexto.
Teste seis casos ruins
Antes do go-live, simule:
| Caso | Resultado esperado |
|---|---|
| ferramenta rejeita entrada inválida | agente pede correção sem fingir indisponibilidade |
| timeout antes da execução | tenta com limite quando há prova de que nada aconteceu |
| timeout depois da execução | verifica pela chave antes de repetir |
| resposta chega atrasada | reconcilia sem mandar duas confirmações conflitantes |
| ferramenta fica indisponível | entra em modo degradado e informa prazo real |
| recuperação também falha | passa para humano com intenção, tentativas e estado conhecido |
Guarde conversa, chamada, resposta, estado no sistema, mensagem ao cliente e ação humana. Teste feliz prova que a integração funciona. Esses seis testam se a operação sobrevive quando ela não funciona.
Quando uma planilha basta
O caminho simples é suficiente quando:
- o volume de ações é baixo;
- poucas ferramentas participam;
- uma pessoa consegue revisar falhas no mesmo turno;
- ações sensíveis exigem confirmação humana;
- existe um identificador para procurar a tentativa;
- o cliente recebe protocolo e retorno realista.
Nesse estágio, use o template, mantenha agentes em modo de sugestão nas ações mais arriscadas e revise toda falha.
Onde começa a quebrar
A revisão manual começa a falhar quando:
- o agente usa várias ferramentas na mesma conversa;
- milhares de ações acontecem por dia;
- retries automáticos podem cobrar, reservar, cancelar ou enviar em duplicidade;
- sistemas retornam estados diferentes;
- não há vínculo entre conversa, chamada e registro no CRM;
- falhas precisam mudar prioridade e fila humana;
- QA não consegue reconstruir a decisão;
- ninguém sabe quais clientes foram afetados por uma indisponibilidade.
Aí não basta escrever “em caso de erro, tente novamente” no prompt. O problema é desenho de operação, integração, observabilidade e responsabilidade.
O que fazer agora
Escolha uma ação que o agente já executa ou pretende executar: consultar pedido, atualizar CRM, marcar horário, cancelar, cobrar ou enviar mensagem.
Preencha o registro de falha de ferramenta. Classifique a ação como leitura, escrita reversível ou escrita sensível. Depois rode os seis casos ruins.
Se a ação envolve agenda, use também Agendamento com IA: o trabalho começa depois da data. Para testar outras falhas de produção, abra O teste da IA não é a demo. É a fila cheia.. Se o agente respondeu sem evidência, revise Quando o agente de IA responde com certeza demais.
Se uma pessoa consegue verificar e corrigir as poucas falhas, resolva sem contratar.
Quando agentes executam ações em volume e a operação precisa ligar conversa, ferramenta, estado, recuperação, handoff, evidência e QA, Zild pode fazer sentido. A conversa comercial vem depois de uma pergunta menos charmosa: quando a ferramenta fica muda, quem sabe o que aconteceu?
Se você prefere ver em vídeo
Eu não encontrei um vídeo em português que eu colocaria como resposta principal para este teste. Há demonstrações de agentes usando ferramentas. Poucas quebram a chamada depois da execução, tentam duplicar a ação e mostram como a operação reconcilia o estado.
Um vídeo útil teria que provocar timeout antes e depois da ação, atrasar a resposta e falhar também na recuperação. Se bastante gente pedir, este assunto entra na fila de gravação. Não é promessa.