Peça, Responda, Termine: para o dinheiro nunca ir para a pessoa errada

A Magie começou como um app de banco para o consumidor e virou a plataforma white-label em que bancos, fintechs e cooperativas de crédito rodam hoje o próprio agente de WhatsApp. Quem manda um Pix pelo app do Banco BV no Brasil, ou um Plin/Yape no Peru, está falando com o próprio banco, não com a gente. O que essa pessoa não vê é que a conversa em si nunca fica em uma coisa só: um Pix, depois uma consulta de saldo, depois outro Pix, tudo na mesma thread.

Nada marca onde um pedido do usuário termina e o próximo começa. Um valor ou um destinatário de um Pix que já foi pode se grudar silenciosamente em um novo algumas mensagens depois, e ninguém percebe até o dinheiro já ter ido.

Aqui estão as mesmas três mensagens, tratadas de duas formas.

Mesma pessoa, mesmas cinco primeiras mensagens. Só a última linha se separa: à esquerda, o novo Pix herda silenciosamente os R$200 do primeiro, três mensagens atrás. À direita, R$100 continua R$100.

Ninguém dentro do modelo fez nada de errado para produzir a coluna da esquerda. Ele leu uma janela de mensagens recentes, encontrou um valor nessa janela e usou. Os R$200 realmente foram ditos, por essa mesma pessoa, nessa mesma conversa. Só não foram ditos sobre este pedido do usuário.

Por que mandar o modelo esquecer não funciona

A primeira correção é óbvia: limpar tudo que o agente lembra assim que um pedido do usuário termina. Isso funciona para o Pix pro Pedro que realmente foi, porque um pagamento concluído dá ao sistema um sinal claro para fazer a limpeza. Não faz nada pelo Pix pro Pedro que nunca foi: aquele que a pessoa mudou de ideia, ou aquele que uma consulta de saldo interrompeu e ninguém voltou para terminar. Esses nunca mandam um sinal dizendo que acabaram, então nada avisa o sistema para esquecê-los, e é exatamente daí que vem a maior parte do vazamento.

A segunda correção é mais simples: é só mandar o modelo não fazer isso, não reaproveitar uma chave ou um valor de um pagamento anterior. Isso ajuda, e vale a pena ter de qualquer jeito. Mas é um pedido de bom comportamento, não uma garantia, e precisa se sustentar em cada chamada, incluindo as que estão sob a maior pressão para simplesmente responder bem: uma mensagem escrita com pressa, faltando uma palavra, que lê quase como uma continuação da anterior. Diga a um modelo como se comportar e, na média, ele vai se comportar assim. No único turno em que errar custa a confiança de alguém, na média não é a régua.

As duas correções tapam o mesmo buraco por fora. Nenhuma faz a pergunta mais básica: o que, neste sistema, representa de fato um pedido do usuário? Uma mensagem é pequena demais, já que um único pedido do usuário pode se espalhar por várias. Uma conversa é grande demais, já que uma conversa comporta muitos pedidos do usuário. Não existia nada no tamanho do meio. Qualquer coisa que devia estar delimitada ao "pedido atual do usuário" estava na verdade delimitada ao que estivesse por perto, porque perto era a única unidade que existia.

Uma janela não consegue dizer onde um pedido do usuário termina. E se alguma coisa no sistema conseguisse?

A Ask

A gente chama essa unidade de Ask. Uma Ask é um pedido do usuário, o mesmo "manda R$50 pro João" de antes, e pode chegar em uma única mensagem ou ser construída ao longo de várias, um pedaço por vez. Cada pedaço de que ela precisa, um valor, uma chave, uma data, é um slot. Uma Ask fica aberta por vez, e ela é resolvida, de um jeito ou de outro, antes de a próxima começar.

Uma Ask tem um ciclo de vida: ela abre quando um novo pedido do usuário começa, se preenche conforme os slots são respondidos, e fecha como concluída, falha ou abandonada. Abandonada é o caso que sustenta tudo, o de um pedido do usuário do qual a pessoa saiu no meio do caminho. Ela é esquecida de propósito, para que a próxima Ask comece do zero em vez de começar do que ficou para trás.

Volte ao exemplo da abertura com essa lente. "Manda um pix pro Pedro" abre uma Ask, é confirmada e fecha como concluída. "Qual meu saldo?" é um pedido do usuário completamente diferente, a própria Ask dele, aberta e fechada em uma única troca. "Manda um pix pra Ana" abre uma terceira Ask, e os únicos slots com que ela começa são os que esta mensagem realmente diz. Os R$200 viviam em uma Ask que já tinha fechado. Não têm de onde vazar.

A mesma fronteira que impede os R$200 de vazar também deixa uma correção barata. Diga "na verdade, é pro João" no meio de um Pix de R$100 pra Maria, e o valor não precisa ser repetido. Você pode mudar de ideia no meio do pedido sem digitar tudo de novo do zero.

Ninguém pergunta a um modelo "isso deveria ser uma nova Ask?" Código determinístico decide, e decide do mesmo jeito toda vez. Os modelos percebem. O código decide.

Onde a fronteira quase quebrou

Três coisas acabaram importando mais do que a ideia de Ask em si.

Diferenciar uma correção de um começo do zero.

"Na verdade, manda pra Maria" e "Manda um pix pra Maria" podem parecer quase idênticas no papel: mesmo destinatário, algumas palavras a mais. A primeira deveria manter o valor que já estava na mesa. A segunda deveria começar do zero, porque, no que diz respeito a este pedido do usuário, nada foi dito ainda. Erre em qualquer uma das direções e alguém percebe na hora: leve o valor adiante quando não devia, e a pessoa acaba confirmando um número que nunca disse; descarte quando não devia, e o agente pergunta de novo algo que acabou de receber. A linha entre as duas está em se a frase lê como emendar algo que já está em andamento ou refazer um pedido do usuário do zero, uma distinção que as pessoas sinalizam de uma dúzia de formas diferentes e fazem sem nunca pensar a respeito.

Um pedido do usuário que esfria.

Alguém manda um pix de um centavo; um preview aparece, esperando a confirmação. Aí nada. A pessoa se distrai, aparece outra coisa, ela não responde. Uma hora depois, ela manda: "dois centavos."

Isso é uma correção do pix que ela nunca confirmou, ou um totalmente novo? Só quem está digitando sabe de verdade, e por um tempo o agente errou o palpite: ele continuava retomando a confirmação antiga, então "dois centavos" virava silenciosamente um pagamento real para quem já estivesse naquela tela pendente.

Acertar isso exige dois sinais, verificados em ordem. A redação vem primeiro: "na verdade, dois centavos" diz explicitamente para corrigir o que já está na mesa; um "dois centavos" sozinho não diz isso. O relógio vem depois: passado um certo intervalo, o pedido antigo esfria independentemente da redação, então o que chegar em seguida começa do zero em vez de pegar um palpite pela metade. Quando nem a redação nem o relógio resolvem, o agente pergunta em vez de adivinhar a qual pedido o novo valor pertence.

Um botão que nunca para de funcionar.

O botão de confirmar embaixo de um preview de Pix não expira sozinho. O WhatsApp mantém todo botão interativo clicável indefinidamente, então um card de uma hora atrás funciona exatamente tão bem quanto um de dez segundos atrás, pelo menos por fora. Se o pedido do usuário por trás dele já fechou, substituído por algo mais novo, um toque naquele botão antigo não deveria fazer nada, e nada na aparência do botão diz isso. É o mesmo fato com que o trabalho de detecção de turno já esbarrou: a gente não é dono do cliente, então não dá para desabilitar visualmente uma mensagem antiga do jeito que um app com a própria interface conseguiria. Um toque contra um pedido do usuário que não está mais aberto é recusado silenciosamente em vez de executado.

O que isso entrega, e onde estamos

O ganho mais claro é o que este post já sugeriu no começo: rastreabilidade. Pergunte quais mensagens produziram uma determinada confirmação de Pix e existe uma resposta exata, esta Ask, estes turnos, estas mensagens, em vez de um palpite montado a partir de uma janela de tempo em torno de quando a confirmação apareceu. Um dos bancos na nossa plataforma pediu exatamente isso: prova, mensagem por mensagem, de como um pagamento foi aprovado.

Essa mesma rastreabilidade é o que também torna o swipe-reply possível. Responda a uma mensagem de vinte minutos atrás e a pessoa retoma exatamente de onde aquela mensagem parou. O que aconteceu depois, uma correção, um pagamento concluído, um abandonado, fica de fora.

O mesmo determinismo se aplica quando algo falha no meio. Digamos que um Pix não passe porque o contato não foi encontrado. Se aquela Ask continua aberta, esperando uma chave corrigida, ou fecha e manda a pessoa para um pedido do usuário novo, é uma regra determinística, não algo que o modelo improvisa na hora. Bancos diferentes querem coisas diferentes aqui: um prefere segurar a Ask e pedir de novo só o pedaço que falta, outro prefere que a pessoa recomece do zero toda vez que uma busca falha. De todo jeito, é uma regra definida uma vez para aquela organização, não renegociada a cada turno.

A mesma fronteira significa que sair de um pedido do usuário não precisa encerrá-lo. Peça ajuda no meio de um Pix, consulte outra coisa completamente diferente, e o Pix ainda pode estar ali depois, esperando exatamente onde foi deixado em vez de pedir para começar de novo.

Mais de um milhão de pessoas hoje usam serviços bancários pela Magie em toda a plataforma, e cada um dos pedidos delas passa por essa mesma fronteira. Na prática, 82,4% das Asks fecham como concluídas, 2,5% são abandonadas antes de chegar a um conjunto completo de slots, e 6,92% são abandonadas porque uma nova Ask as substituiu no meio do caminho. O que já sustenta o peso hoje é a estrutura em si, não uma taxa calculada em cima dela.

A mesma fronteira segue para onde a Magie está indo: conforme o assistente único se divide em vários especializados, cada um mantém as próprias Asks em vez de compartilhar um pool só.

Mais adiante, isso é uma direção e não uma funcionalidade entregue. Uma vez que existe um registro limpo do que alguém realmente pediu, encerrado de um jeito ou de outro, duas coisas se tornam possíveis em cima disso. Uma é responder de forma direta quando pedirem para olhar para trás, quantos Pix neste mês, se a transferência da semana passada foi. A outra está mais à frente ainda: um agente que começa a antecipar um pedido do usuário antes de ele estar totalmente escrito, porque tem um histórico real dos pedidos dessa pessoa para consultar em vez de um palpite feito do zero toda vez. Para uma plataforma feita para rodar sob a marca de outros bancos, isso é personalização em uma escala diferente da que estamos acostumados: um agente por pessoa, não um agente por organização. As duas possibilidades precisam exatamente do que uma Ask já guarda, uma fronteira em volta do que foi realmente pedido e um registro honesto do que aconteceu com ele.

Esse registro só continua honesto pelo mesmo motivo que os R$200 não vazam para o próximo pedido do usuário hoje: uma Ask abandonada realmente desaparece, de propósito, em vez de ficar ali como um rascunho pela metade fazendo as vezes de algo real. Os R$200 ou pertencem a um pedido do usuário que ainda está aberto, ou não pertencem a lugar nenhum, e acertar essa resposta, toda vez, é para isso que existe uma Ask.