Roteamento multiagente e o supervisor que guarda o dinheiro

O problema

Uma conversa de WhatsApp, um cliente do outro lado, e atrás dela um time de Especialistas: recepção, agenda, vendas, cobrança e, quando o caso pede, uma pessoa. O cliente não sabe com qual deles está falando, e não precisa saber. Quem decide é o sistema, mensagem por mensagem, protegendo uma coisa acima das outras: o dinheiro. Roteia errado e a recepção solta um preço que ninguém autorizou. Supervisiona errado e sai uma cobrança errada.

As restrições

• 01Uma carteira só, várias vozes. Não importa quem responde: total, preço e código de pagamento têm que ser os números reais da empresa, nunca um valor improvisado pra conversa fluir.
• 02O roteamento não pode perguntar pro cliente. "Digite 1 para vendas" é justo o atrito que o produto veio tirar; a intenção tem que sair da própria mensagem.
• 03Especialista não passa do papel dele. A recepção atende, mas não vende — é cruzando essa linha que preço acaba saindo inventado.
• 04No dinheiro, na dúvida não manda. Se uma trava não tem certeza de que o número é real, a mensagem fica segurada.

A arquitetura

Rotear só por intenção não bastou. "Quero 10 fardos" não é uma pergunta que a recepção consiga responder: a quantidade colada na unidade já é o sinal de compra. Então o roteador passou a ler a estrutura da mensagem, e não só o assunto — quantidade junto de unidade vai pra Vendas mesmo quando a frase parece conversa fiada. E antes de qualquer resposta com valor sair, o supervisor do dinheiro reconfere preço, total e Pix contra o que as ferramentas devolveram.

A parte difícil

O supervisor do dinheiro era a rede de segurança, e quase estrangulou o que estava protegendo. Na primeira versão ele acusava de mentira qualquer número que o agente não tivesse acabado de buscar. E aí ele mesmo repassava um total velho.

O problema era de timing. O prompt do supervisor era montado com o valor do carrinho lido antes das ferramentas daquele turno rodarem. Dentro do mesmo turno o agente aplicava o desconto por volume, e o supervisor comparava o total certo, já com desconto, contra o número que tinha guardado antes — e chamava o agente de mentiroso. A correção virou regra: todo valor que pode mudar no meio do turno volta no resultado da ferramenta, em vez de ser lido uma vez no começo. Depois disso ele passou a conferir contra o que a ferramenta acabou de devolver.

Trade-offs

• Cada passada do supervisor custa um segundo e uma chamada de modelo, em toda resposta que envolve valor. Um Pix errado sozinho custa mais do que um mês dessa latência.
• O roteamento inferido erra de vez em quando. Na dúvida eu puxo pra Vendas de propósito: perder uma venda é pior do que a recepção educadamente chamar um vendedor.
• Vários Especialistas dão mais prompt pra manter do que um agente faz-tudo. Mas é essa separação que deixa cada um auditável, e é ela que torna as travas possíveis.

O que eu faria diferente

As regras de roteamento cresceram como caso especial atrás de caso especial: quantidade e unidade, depois mais um, depois outro. Funciona e está testado, mas cada sinal novo significa mexer numa função que só engorda. Eu transformaria cada sinal num predicado com nome, testável sozinho, pro roteador virar quase uma tabela de "essa forma de mensagem significa essa intenção". No dia em que entrar mais um Especialista, seria acrescentar uma linha em vez de costurar uma condição nova no meio das que já existem.