Quando uma automação responde bem, o handoff humano parece um detalhe de interface: alguém clica em “assumir” e a IA deixa de responder. Essa leitura desaparece no primeiro caso de concorrência real.
Uma mensagem pode já estar numa fila. O modelo pode estar gerando uma resposta. Um webhook pode ser entregue duas vezes. O operador pode assumir a conversa em outro dispositivo enquanto uma retentativa antiga continua viva. Se a arquitetura trata handoff como um booleano consultado no começo do fluxo, duas autoridades passam a agir sobre o mesmo cliente.
O problema principal não é qualidade do prompt. É coordenação de estado.
Handoff é transferência de autoridade
O sistema precisa responder uma pergunta antes de produzir qualquer efeito: quem tem autoridade para falar por esta conversa agora?
Essa autoridade não pertence ao modelo, à fila nem à tela do operador. Ela pertence ao domínio da conversa. Uma máquina de estados simples já torna o desenho mais claro:
- AI_ACTIVE: a política permite automação, mas cada resposta ainda precisa ser validada;
- HANDOFF_PENDING: existe uma transferência em andamento e novos trabalhos automáticos não podem começar;
- HUMAN_ACTIVE: somente o operador atual pode autorizar mensagens de saída;
- AI_SUSPENDED: a automação está bloqueada por regra, falha ou revisão, mesmo sem um operador ativo.
Os nomes podem mudar. O importante é que a transição seja atômica, versionada e observável. “Humano ativo” não pode ser apenas um atributo visual atualizado depois que os jobs antigos já foram liberados.
Handoff seguro não encerra apenas a próxima geração. Ele revoga a autoridade de todo trabalho automático que nasceu de uma versão anterior da conversa.
A corrida que o happy path não mostra
Considere uma sequência curta:
- A mensagem do cliente M42 chega e cria o trabalho J18.
- J18 lê que a conversa está em AI_ACTIVE e solicita uma resposta ao modelo.
- Antes do retorno, uma operadora assume a conversa.
- A operadora responde manualmente.
- J18 recebe a conclusão do modelo e envia uma segunda mensagem.
Nenhum componente “falhou”. Cada parte fez exatamente o que sabia fazer. O defeito está no contrato entre leitura e efeito: J18 verificou a autoridade cedo demais e assumiu que ela continuaria válida.
O mesmo problema aparece em follow-ups, agendamentos e mudanças no CRM. Cancelar a chamada do modelo reduz custo, mas não é garantia de correção. O processo pode não receber o cancelamento, uma resposta pode já ter sido persistida ou uma retentativa pode reaparecer depois.
Separe proposta, política e efeito
Uma resposta gerada deve ser tratada como proposta, não como efeito autorizado. O caminho mais seguro possui pelo menos três momentos distintos:
- Proposta: o modelo recebe contexto permitido e produz uma resposta candidata.
- Política: o serviço relê a versão e o dono atuais da conversa, valida restrições e decide se a proposta ainda pode sair.
- Efeito: uma mensagem autorizada recebe chave idempotente, entra na outbox e só então segue para o canal.
Essa segunda leitura é essencial. Entre gerar e enviar, o mundo pode ter mudado. A política precisa comparar a versão de autoridade usada para criar o job com a versão atual. Se elas divergirem, o trabalho termina como obsoleto, não como erro a ser repetido.
No case técnico do Auto Whats, esse princípio aparece como invariante: somente o dono atual da conversa pode autorizar uma resposta de saída.
Versão vence booleano
Um campo como aiEnabled informa uma preferência, mas não prova que um trabalho ainda tem permissão. Acrescente uma versão monotônica de autoridade — por exemplo, authorityVersion.
Quando o job nasce, ele guarda:
- identificador da conversa;
- versão de autoridade observada;
- identificador da mensagem que o originou;
- política aplicada;
- chave de correlação.
Quando um humano assume, a transação muda o estado, incrementa a versão e registra o novo dono. Antes do envio, o job compara sua versão capturada com a versão corrente. Uma desigualdade invalida o efeito, mesmo que a geração tenha terminado com sucesso.
Esse mecanismo também ajuda na devolução para a IA. Reativar automação cria uma nova época da conversa; jobs de épocas anteriores continuam inválidos e não ressuscitam por acidente.
Idempotência precisa atravessar o canal
Webhooks e filas operam com entrega pelo menos uma vez em muitos desenhos reais. Isso significa que “recebi a mensagem” e “processei uma única vez” são afirmações diferentes.
A deduplicação pode combinar o identificador externo da mensagem com a conta e o canal. O envio precisa de outra chave, derivada da causa e da versão autorizada. Assim, repetir um handler não cria uma nova mensagem apenas porque a primeira confirmação demorou.
Uma outbox transacional ajuda a conectar estado interno e efeito externo:
- a decisão autorizada e o registro de saída são gravados juntos;
- um worker envia itens pendentes;
- a confirmação atualiza o mesmo item;
- retentativas reutilizam a chave idempotente;
- uma versão de autoridade revogada impede itens ainda não enviados.
Isso não cria exatamente uma vez no mundo inteiro. Cria um contrato explícito para tornar duplicidade detectável, recuperável e limitada.
Cancelamento é otimização; invalidação é correção
Abortar uma requisição ao modelo, remover um job da fila e interromper streaming são boas otimizações. Elas economizam tempo e reduzem a chance de um efeito tardio. Nenhuma delas substitui a validação no ponto de envio.
O desenho deve continuar correto se o cancelamento chegar tarde. Essa é uma forma prática de pensar em concorrência: cancelamento melhora o caminho comum; versão e política protegem o invariante.
Também vale distinguir trabalho obsoleto de trabalho com falha. Uma resposta descartada porque o humano assumiu não deve inflar alarmes de erro. Ela é um resultado esperado da coordenação e merece uma razão própria, como authority_revoked.
Contexto sem transformar conversa em depósito
Handoff exige contexto suficiente para que a pessoa continue o atendimento. Isso não autoriza enviar todo o histórico para todo modelo nem guardar texto indefinidamente.
Uma arquitetura responsável separa:
- eventos operacionais necessários para consistência;
- trechos permitidos para compor contexto do modelo;
- resumo útil para o operador;
- dados sensíveis que precisam de mascaramento, retenção curta ou exclusão;
- métricas agregadas que não dependem de conservar a conversa integral.
O operador deve entender por que recebeu o handoff: baixa confiança, pedido explícito, política comercial, falha de integração ou decisão manual. “A IA desistiu” é um diagnóstico pobre e dificulta tanto a experiência quanto a melhoria do sistema.
Observe a transição, não apenas o volume
Contar mensagens automáticas diz pouco sobre segurança. Sinais melhores acompanham a fronteira:
- trabalhos invalidados após mudança de autoridade;
- tempo entre pedido de handoff e confirmação visível;
- mensagens bloqueadas por versão obsoleta;
- duplicidades interceptadas por chave idempotente;
- respostas humanas que corrigem uma proposta automática;
- retomadas da IA depois do encerramento humano;
- sessões em que fila, banco e canal divergem por tempo excessivo.
Esses indicadores não precisam carregar o conteúdo completo. Correlação, motivo, versão, latência e resultado costumam ser suficientes para investigar o fluxo sem transformar observabilidade em coleta irrestrita.
Teste as interleavings perigosas
Um teste feliz cobre mensagem, geração e envio. Um sistema concorrente precisa testar ordens alternativas:
- humano assume antes de o job começar;
- humano assume durante a geração;
- humano assume depois da outbox, antes do envio;
- webhook duplicado chega em dois workers;
- confirmação do canal expira e a retentativa começa;
- a conversa volta para a IA enquanto um job antigo ainda existe;
- dois operadores tentam assumir ao mesmo tempo;
- o processo reinicia entre decisão e efeito.
Relógio controlável, IDs determinísticos e adaptadores falsos tornam essas sequências reproduzíveis. O objetivo não é simular toda a infraestrutura; é provar que o invariante permanece verdadeiro em cada ponto de interrupção.
Falhar com segurança também é experiência
Quando a autoridade é incerta, o sistema deve preferir silêncio controlado a duas vozes concorrentes. Isso não significa abandonar o cliente. A interface pode mostrar trabalho pendente, sugerir resposta ao operador, criar alerta e permitir retomada explícita.
Uma falha segura precisa ser legível. Se a automação foi bloqueada, o operador deve saber o motivo e a ação possível. Se uma mensagem ainda depende de confirmação do canal, a tela não deve apresentá-la como entregue. Correção de sistema e clareza de produto se encontram no mesmo estado.
A pergunta certa vem antes do modelo
Modelos melhores reduzem respostas ruins. Eles não resolvem autoridade, idempotência, reentrega nem disputa entre trabalhos. Essas são propriedades do sistema que envolve a IA.
Antes de escolher prompt, provedor ou tamanho de contexto, escreva o invariante: apenas a autoridade corrente pode produzir um efeito externo. Depois desenhe versão, política, outbox, cancelamento, motivos e testes ao redor dele.
Essa arquitetura não vale apenas para WhatsApp. Agentes que enviam e-mail, alteram CRM, aprovam tarefas ou executam ferramentas enfrentam a mesma fronteira. A IA pode propor rápido. O produto precisa decidir com segurança.
Leia também IA com limites: por que a arquitetura vem antes do prompt e use o briefing técnico para navegar pelos demais sistemas.
