Transbordo Humano em Agentes de IA no WhatsApp: Playbook de Produção
Desenhe o transbordo humano de um agente de IA no WhatsApp com gatilhos, estado, contexto, aceite, recuperação e métricas.
Transbordo Humano em Agentes de IA no WhatsApp: Playbook de Produção
Transbordo humano em um agente de IA no WhatsApp é a transferência controlada da responsabilidade pela conversa da automação para uma pessoa ou fila nomeada. A transferência só termina quando o agente para de responder, o caso chega ao destino certo com contexto suficiente, uma pessoa aceita e o cliente entende o que acontecerá depois.
Uma mensagem dizendo “vou transferir você” não é transbordo. Sem estado, roteamento, aceite e recuperação, ela é apenas uma promessa.
Este playbook foca esse limite de produção. Para configuração do canal e arquitetura, comece pelo guia amplo de integração de IA no WhatsApp da empresa.
O contrato do transbordo
| Pergunta | Decisão obrigatória |
|---|---|
| Por que a automação para? | Gatilho explícito e testável |
| Quem recebe a conversa? | Pessoa, time ou fila nomeados |
| O que o responsável recebe? | Resumo, motivo, questão aberta, ações e transcrição |
| Quando o cliente recebe retorno? | Expectativa honesta baseada na operação real |
| Quem é dono da conversa durante a espera? | Uma fonte de estado e um responsável atual |
| Como a automação retorna? | Evento explícito de encerramento ou devolução |
| O que acontece se o roteamento falhar? | Responsável alternativo e alerta visível |
Se qualquer linha não tiver resposta, o transbordo ainda não está pronto para clientes reais.
Modele o transbordo como estado da conversa
O desenho mais seguro trata responsabilidade como estado persistido, não como instrução no prompt.
| Estado | Responsável | Comportamento permitido |
|---|---|---|
ai_active | Agente de IA | Responder dentro do escopo e usar ferramentas aprovadas |
handoff_requested | Sistema de roteamento | Bloquear novas respostas autônomas e montar o caso |
queued | Fila humana | Manter automação parada, receber mensagens e atualizar o caso |
human_active | Pessoa nomeada | Pessoa responde, IA pode ajudar em privado quando permitido |
resolved | Pessoa ou workflow | Registrar resultado e encerrar a escala |
ai_resumed | Agente de IA | Retornar somente após evento explícito e nova checagem de contexto |
A transição para handoff_requested precisa bloquear a saída autônoma antes de enviar a mensagem de transferência ao cliente. Caso contrário, bot e pessoa podem responder ao mesmo tempo.
Persista o estado fora do modelo de linguagem. Depois de um reinício ou reentrega de webhook, o sistema ainda precisa saber quem é dono da conversa.
1. Defina os gatilhos de transbordo
Use regras determinísticas quando possível e julgamento do modelo apenas quando a interpretação de linguagem for realmente necessária.
| Gatilho | Exemplo | Comportamento recomendado |
|---|---|---|
| Pedido do cliente | “Quero falar com uma pessoa” | Transferir sem discutir ou forçar mais etapas no bot |
| Limite de política | Exceção de reembolso, ameaça jurídica, conselho regulado | Parar antes de decidir fora do escopo |
| Ação sensível | Mudança de pagamento, recuperação de conta, atualização irreversível | Exigir revisão ou aprovação humana |
| Falta de autoridade | Sistema ou credencial necessária indisponível | Transferir nomeando a dependência ausente |
| Falha repetida | Mesma intenção falha nas tentativas definidas | Encerrar o loop e preservar passos tentados |
| Baixa garantia | Registros conflitantes ou evidência insuficiente | Fazer uma pergunta útil ou transferir |
| Regra comercial | Oportunidade qualificada precisa de vendedor | Rotear para o responsável comercial correto |
| Falha operacional | Fila, modelo, integração ou canal degradado | Usar o caminho alternativo testado |
Sentimento pode apoiar a prioridade, mas não deve ser o único gate. Um cliente calmo pode ter um problema de alto impacto, e uma mensagem frustrada ainda pode ser resolvida com segurança por um caminho conhecido.
Evidência de produção: tabela versionada de gatilhos, exemplos que devem transferir e exemplos que devem continuar na automação.
2. Pare a automação antes de anunciar a transferência
A ordem importa:
- receba e deduplique o evento do WhatsApp;
- avalie o gatilho de transbordo;
- mude atomicamente a responsabilidade para fora de
ai_active; - crie ou atualize o caso;
- encaminhe para uma pessoa ou fila;
- confirme que o destino aceitou o caso;
- envie ao cliente a mensagem de estado apropriada.
Se o encaminhamento não puder ser confirmado, não afirme que uma pessoa recebeu a conversa. Use um fallback honesto, como “Não consegui conectar o time ainda. Seu pedido foi registrado e o responsável pelo atendimento recebeu um alerta.”
O OpenClaw documenta um caminho de entrada que passa por roteamento, estado da sessão, deduplicação, fila, execução do agente e entrega da resposta. A camada de transbordo do negócio deve atuar antes da saída autônoma e manter o estado de responsabilidade durável nesse caminho.
3. Transfira o contexto mínimo útil
A pessoa não deve precisar reler toda a conversa para entender a situação. O registro do transbordo deve conter:
- referência da conversa e do cliente usada pelo negócio;
- motivo e gatilho do transbordo;
- resumo factual curto;
- pedido atual ou pergunta aberta do cliente;
- dados já coletados;
- ações e ferramentas já tentadas;
- resultados, erros e aprovações;
- risco ou urgência conforme regra do negócio;
- fila de destino e responsável atribuído;
- horários de pedido, roteamento e aceite;
- link para a conversa ou transcrição original.
Mantenha a conversa bruta acessível, porque um resumo gerado por IA pode omitir ou distorcer detalhes. Minimize os dados pessoais copiados e preserve as regras de acesso dos sistemas de origem.
Exemplo de payload do transbordo
{
"conversationId": "wa_123",
"state": "queued",
"reason": "customer_requested_human",
"summary": "Cliente precisa alterar um pedido depois do envio.",
"openQuestion": "O endereço de entrega ainda pode ser alterado?",
"attemptedActions": ["order_lookup"],
"ownerQueue": "order_support",
"requestedAt": "2026-07-27T21:00:00Z",
"transcriptUrl": "internal://conversation/wa_123"
}
Este é um exemplo de arquitetura, não um schema universal. Use identificadores e campos compatíveis com a fonte de estado da empresa.
4. Exija aceite
Encaminhamento não é aceite. Um desenho confiável registra:
- o caso chegou ao destino pretendido;
- uma pessoa ou fila confirmou o recebimento;
- um responsável nomeado assumiu;
- a primeira resposta humana chegou à conversa no WhatsApp.
Defina expectativas a partir da agenda e da fila reais, não de tempos inventados. Fora do horário de atendimento, diga que o pedido foi registrado, informe a janela relevante quando aprovada pelo negócio e ofereça caminho de emergência apenas se ele realmente existir.
Se ninguém aceitar dentro da regra do negócio, alerte o responsável alternativo. Não devolva silenciosamente a conversa para a automação.
5. Mantenha um responsável visível
Durante human_active, respostas autônomas ao cliente devem continuar bloqueadas. A IA pode ajudar o operador em privado com resumo, consulta de registros ou rascunho, mas o envio final segue a política do modo humano.
A experiência do cliente não deve exigir outro número nem repetir toda a explicação quando a arquitetura consegue preservar a mesma conversa. Se um novo canal ou ticket for inevitável, explique a transição e carregue o contexto original.
Em canais baseados em OpenClaw, política de acesso, bindings e chaves de sessão determinam qual agente recebe uma conversa do WhatsApp. O modelo não escolhe a rota de transporte. O estado do transbordo deve ser imposto pela aplicação ou camada operacional, não apenas pelas instruções do modelo.
6. Defina encerramento e retorno
A automação não deve voltar porque um tempo passou. Exija um evento explícito, como:
- pessoa marca o caso como resolvido;
- pessoa devolve a conversa para a IA com um motivo;
- workflow encerra depois de um resultado verificado;
- cliente inicia nova intenção depois do caso anterior ser fechado.
Antes de retornar para ai_active, atualize o contexto e confirme que nenhuma ação sensível ou promessa segue aberta. Registre quem retomou a automação e por quê.
Se a pessoa parar de responder sem fechar o caso, mantenha a responsabilidade visível e alerte a fila. Um timeout oculto cria o mesmo risco de resposta dupla de uma máquina de estados ausente.
7. Teste os caminhos de falha
No mínimo, teste:
| Cenário | Evidência esperada |
|---|---|
| Cliente pede uma pessoa | Automação para e um único caso é criado |
| Modelo não reconhece o pedido | Frase determinística ou controle do operador ainda transfere |
| Webhook duplicado chega | Não existe caso nem mensagem duplicada |
| Cliente escreve enquanto espera | Mensagem entra no mesmo caso |
| Pessoa e IA tentam responder | Somente o responsável atual consegue enviar |
| Fila está indisponível | Responsável alternativo recebe alerta visível |
| Processo reinicia | Estado persistido continua bloqueando a IA |
| Pessoa resolve e devolve | Contexto é atualizado antes da automação voltar |
| Cliente envia dado sensível | Regras de acesso e retenção continuam aplicadas |
Rode os testes com um número que não seja de cliente antes de abrir o fluxo. Depois monitore exceções reais e adicione ao conjunto de avaliação.
8. Meça o transbordo como loop operacional
Acompanhe:
- taxa de transbordo por gatilho e intenção;
- pedidos de transferência que falharam ao criar caso;
- tempo entre pedido e aceite da fila;
- tempo entre pedido e primeira resposta humana;
- conversas abandonadas durante a espera;
- resultado de resolução depois da transferência;
- respostas duplicadas ou conflitantes;
- casos devolvidos para a IA;
- novos transbordos do mesmo assunto não resolvido;
- feedback do cliente quando a empresa já o coleta.
Não otimize somente para uma taxa menor de transbordo. Uma taxa muito baixa pode indicar que o agente resolve mais, ou que se recusa a parar quando deveria. Revise contenção junto com qualidade de resolução, resultado para o cliente e risco.
O AI RMF do NIST orienta que processos de supervisão humana sejam definidos, avaliados e documentados, com monitoramento em produção e planos de resposta e recuperação. As métricas do transbordo fazem parte dessa evidência.
Perguntas frequentes
Quando um agente de IA no WhatsApp deve transferir para uma pessoa?
Transfira quando o cliente pedir, a solicitação sair da política ou autoridade, a ação for sensível, a evidência for insuficiente, tentativas repetirem sem progresso, uma oportunidade qualificada precisar de responsável ou o caminho automatizado estiver degradado.
A IA deve enviar um resumo para a pessoa?
Sim, como auxílio de navegação. Inclua motivo, questão aberta, fatos relevantes e ações tentadas, mantendo a conversa original disponível para verificação.
A IA pode continuar respondendo enquanto uma pessoa assume?
Não ao cliente por padrão. Um responsável visível evita mensagens contraditórias ou duplicadas. A IA pode ajudar o operador em privado quando a política permitir.
Como o bot sabe quando voltar?
Use um evento explícito de encerramento ou devolução pela pessoa ou workflow. Não dependa somente de tempo decorrido ou palpite do modelo.
O WhatsApp fornece todo o sistema de transbordo?
O WhatsApp fornece o canal de comunicação e capacidades da plataforma. Estado de responsabilidade, fila, aceite do operador, contexto do caso, fallback e retomada pertencem à aplicação e ao processo operacional ao redor.
Referências primárias
- Documentação do canal WhatsApp no OpenClaw
- Ciclo de mensagens e entrega do OpenClaw
- Guia prático da OpenAI para construir agentes
- Core do AI Risk Management Framework do NIST
Transbordo é infraestrutura de produção, não copy de conversa. Mapeie a implementação de um agente de IA no WhatsApp com responsabilidade, contexto, aceite e recuperação explícitos antes de o primeiro cliente real alcançar o agente.