O cliente clica duas vezes ou manda "oi" de novo — a IA agenda ou manda o link de pagamento duas vezes?
Não. Numa IA de atendimento bem montada, toda ação que tem efeito no mundo real — agendar um horário, mandar o link de pagamento, abrir uma ficha no CRM — carrega uma chave de idempotência: o mesmo pedido, repetido, não dispara a ação de novo. Se o cliente manda "oi?" três vezes seguidas ou clica duas vezes no botão errado, a IA reconhece que já tratou aquilo e não age em duplicidade. Quem falha nisso é o chatbot que trata cada clique como um pedido novo — e manda dois links, ou confirma o mesmo agendamento duas vezes.
Por que "clicar duas vezes" é tão comum no WhatsApp?
Ninguém faz isso por querer atrapalhar. O cliente manda "oi?" de novo porque a resposta demorou uns segundos; clica duas vezes num botão porque o celular travou meio segundo; reenvia a mesma pergunta porque saiu do app e voltou sem saber se ela chegou. É comportamento normal de quem usa WhatsApp no dia a dia — e é por ser normal que o agente não pode tratar cada repetição como um pedido novo.
O problema aparece quando a repetição chega numa ação que mexe em algo fora da conversa: reservar um horário, mandar um link de pagamento, abrir um registro no CRM. Responder "oi, tudo bem?" duas vezes não machuca ninguém. Agendar o mesmo horário duas vezes, ou mandar dois links pro mesmo pedido, confunde o cliente e vira problema de verdade — cobrança duplicada, horário em dobro, ficha repetida.
O que muda quando a ação tem efeito no mundo real?
No desenho de um SDR de IA existe uma linha entre gerar texto (responder, explicar, perguntar) e acionar uma ferramenta que produz efeito fora da conversa — uma "tool", no jargão do harness. Gerar texto de novo não tem risco: no pior caso, o modelo reformula a mesma resposta. Já uma tool que agenda, cobra ou registra precisa de uma garantia a mais: rodar uma vez só, mesmo se for chamada duas vezes.
Essa garantia é a idempotência, e no catálogo de ferramentas de um agente sério ela não é decidida caso a caso — é regra fixa do motor, igual pra qualquer cliente. Muda o pacote de ferramentas (agenda pra clínica, link de pagamento pro comércio, ficha de imóvel pra imobiliária); não muda a exigência de cada uma ser segura contra repetição.
Como isso funciona sem travar o agente ou pedir confirmação toda hora?
A ferramenta que age no mundo real carrega uma chave que identifica aquele pedido específico — "isso é a mesma tentativa de novo", não "isso parece igual mas é outro pedido". Antes de executar, ela confere se já existe um registro com essa chave:
- Não existe → roda normal e grava o registro.
- Existe e já deu certo → não executa de novo, devolve que já estava feito.
- Existe mas falhou (erro de rede, instabilidade momentânea) → tenta de novo de verdade, porque a ação nunca chegou a acontecer.
Essa terceira regra é o detalhe que separa um desenho ingênuo de um bem pensado: idempotência não é "nunca repetir a ação", é "nunca repetir a ação que já teve sucesso". Uma trava boba que bloqueasse qualquer segunda tentativa deixaria o cliente sem resposta justamente quando a primeira falhou por motivo técnico.
E o debounce na entrada não resolveria isso sozinho?
São duas travas diferentes, e as duas precisam existir juntas. O debounce cuida da entrada: quando o cliente manda "oi?", "oi??" e "alguém aí?" em rajada, o agente espera uma janela curta e junta os fragmentos num pedido só, em vez de reagir a cada bolha isolada.
Mas debounce resolve a rajada rápida, de segundos. Não resolve o "oi?" repetido um minuto depois, nem o clique duplo que já virou dois eventos separados antes de a IA processar qualquer coisa. Por isso a idempotência da ação continua necessária mesmo com o debounce funcionando: uma trava organiza o que chega picado na entrada; a outra impede que uma ação com efeito real rode duas vezes na saída, não importa de onde veio a repetição. O mesmo raciocínio de juntar antes de agir aparece em como o agente escreve — ali é ritmo de resposta, aqui é segurança da ação.
O que o cliente sente quando isso está bem montado?
Nada — e é esse o ponto. Quem manda "oi?" três vezes recebe uma resposta coerente, não três. Quem clicou duas vezes recebe um agendamento, não dois avisos de confirmação brigando entre si. A trava só fica visível quando falta, e aí vira reclamação: "vocês me cobraram duas vezes" ou "apareceram dois horários marcados no meu nome".
No agente que a Estefani & Co roda ao vivo no WhatsApp, a ferramenta que manda qualquer mensagem de saída — inclusive um link — exige uma chave de idempotência em toda chamada, e essa chave vira um índice único no banco por cliente. A regra testada é específica: se já existe um registro daquele envio marcado como concluído, a ferramenta não aciona o WhatsApp de novo — devolve vazio, sem duplicar. Mas se o registro existir com status de falha (a chamada anterior caiu por erro de rede), ela tenta de novo de verdade, porque a mensagem nunca chegou a sair. A mesma lógica se repete na ferramenta que cria lead no CRM — idempotente por telefone, então o mesmo contato não vira duas fichas — e na que muda o estágio do funil, que não grava um segundo evento se a transição já tinha sido registrada. É a mesma peça de desenho em três ferramentas diferentes: nenhuma ação com efeito fora da conversa roda duas vezes pro mesmo pedido, mas nenhuma trava também quando a tentativa anterior de fato falhou.
Perguntas frequentes
Se o cliente mandar um pedido novo parecido, tipo "quero remarcar", a IA ignora?
Não. Idempotência trava a repetição do MESMO pedido, não pedidos diferentes que se parecem. Remarcar tem sua própria chave — a IA distingue.
Isso deixa a IA mais lenta pra responder?
Não de forma perceptível. É uma consulta rápida antes de executar a ação; o cliente sente o mesmo tempo de resposta de sempre.
E se a primeira tentativa falhou de verdade — o cliente fica sem o link de pagamento?
Não. A trava só bloqueia repetir uma ação que JÁ deu certo. Se a tentativa anterior falhou por erro técnico, a próxima executa normalmente e o cliente recebe o link.
É a mesma coisa que o debounce das mensagens picadas?
Não, são complementares. O debounce junta mensagens na entrada, antes de decidir o que responder. A idempotência trava a ação na saída, pra ela não rodar duas vezes.
Vale só pra agendamento e pagamento?
Qualquer ferramenta com efeito fora da conversa — agendar, mandar link, abrir ficha, mudar estágio no CRM — segue essa regra. É parte fixa do motor, não algo configurado só pra um cliente.