Ouvir, esperar, responder: como fazer agentes soarem naturais

A Magie nasceu como um app de banco para pessoas e evoluiu para uma plataforma white-label que permite a bancos, fintechs e cooperativas lançarem e operarem seu próprio canal no WhatsApp. Hoje, várias instituições usam nossa plataforma, entre os clientes que já anunciamos publicamente estão o Banco BV, no Brasil, e um banco no Peru.

Em uma solução conversacional, nossa preocupação é entregar uma experiência que soe como falar com uma pessoa, em vários aspectos. Um agente personalizado, que parece conhecer você e antecipa o que você precisa porque guarda memórias das interações anteriores. E, principalmente, um agente que espera você terminar de falar em vez de responder a cada mensagem, como em uma conversa humana, em que as pessoas esperam o que a outra tem a dizer e sabem exatamente quando é a sua vez.

Veja o mesmo pedido, tratado de duas formas por um produto conversacional:

As mesmas duas mensagens, a mesma pessoa, o mesmo valor. No primeiro caso, o agente se antecipa antes de a segunda mensagem chegar, pergunta justamente a informação que já estava a caminho e responde de novo quando ela aparece. No segundo, ele apenas espera e diz uma coisa só, quando há algo a dizer.

Ninguém desenharia o primeiro caso de propósito. Mas é o que se obtém por padrão no momento em que um agente responde a cada mensagem conforme ela chega, e é uma armadilha fácil de cair sem perceber, porque cada resposta isolada parece razoável.

O problema: responder tudo, ou fazer todo mundo esperar

Construímos essa solução para a marca de outras empresas, então a pessoa do outro lado do chat confia no próprio banco, não em nós pelo nome. Isso eleva um pouco mais as apostas. Interromper alguém no meio da explicação de quanto dinheiro mandar e para quem é dizer, sem querer, que você não estava realmente escutando. Faça isso duas vezes no mesmo pedido e a pessoa começa a duvidar de tudo o que você responde, inclusive da parte em que você confirma que o Pix saiu.

Há o outro lado: esperar antes de responder qualquer coisa traz suas próprias dúvidas. Você manda uma mensagem, ela fica ali parada, e começa a suspeitar que algo quebrou, que o app travou, que a mensagem nunca foi enviada. Ninguém raciocina conscientemente sobre isso. É o mesmo instinto que faz você olhar para o rosto de alguém no meio da frase para checar se a pessoa ainda está ali.

As duas falhas vêm da mesma peça faltando: nada do outro lado sabe quando você terminou de falar. Produtos como o ChatGPT escapam de parte disso de graça, porque são donos da interface, dá para desabilitar a caixa de texto enquanto pensam, e você fisicamente não consegue mandar uma segunda mensagem no meio do turno. O WhatsApp não nos dá essa alavanca. Não controlamos o cliente, então nada impede alguém de disparar cinco mensagens seguidas sem nenhum sinal na tela pedindo para esperar. Uma pessoa resolve isso sem pensar. Nós tivemos que construir.

Existe um incentivo de negócio aqui, além do de experiência. A Meta vem migrando a precificação do WhatsApp Business de cobrança por conversa para cobrança por mensagem e, a partir de outubro de 2026, isso vale também para as respostas de serviço dentro de uma conversa aberta, exatamente o tipo de troca deste post. No modelo antigo, três respostas para resolver um Pix custavam o mesmo que uma. No novo, não custam. Menos respostas, mais bem cronometradas, deixam de ser apenas a forma educada de conduzir a conversa e passam a ser também a mais barata.

Por que uma janela fixa não vence

A solução óbvia é a primeira que a maioria dos produtos conversacionais tenta: acumular mensagens por um tempo determinado, tratar o silêncio como fim de turno e processar tudo o que chegou em lote. É um semáforo. Verde enquanto as mensagens caem, vermelho quando o relógio estoura, e só então algo é processado. Isso resolve o primeiro cenário de vez: ninguém é interrompido no meio do raciocínio, porque nada é lido até a pessoa parar de digitar.

Mas cria uma falha nova, justamente em quem nunca precisou daquela espera.

É um pedido completo parado em um buffer, cumprindo um relógio de que nunca precisou. A gente esbarrou nisso numa versão inicial, em que a própria ideia de turno estava amarrada à janela de ociosidade, na prática, cada mensagem virava um turno. Tentamos alongar a espera para capturar mais quem digita em rajada e sentimos o efeito imediatamente do outro lado: cada segundo extra comprado para quem escreve em fragmentos é cobrado de quem escreveu tudo de uma vez, que é a maioria dos nossos usuários frequentes.

Não existe janela que sirva aos dois grupos. Encurte e os fragmentados são cortados de novo. Alongue e quem manda tudo numa mensagem paga imposto por um hábito que não tem.

O problema é amarrar a espera a um relógio. O que um relógio não sabe fazer é ler a mensagem. E se algo lesse?

Um pequeno motor de IA, e um sistema em volta dele

O que um relógio não faz, um motor inteligente faz. Construímos esse motor de IA para rodar em cada mensagem, antes de qualquer outra coisa no pipeline, então o veredito precisa chegar em milissegundos, não nos segundos que um modelo mais pesado gastaria raciocinando. Por isso o desenvolvemos internamente, em vez de chamar um modelo de linguagem grande e remoto a cada mensagem de uma conversa.

O motor vive dentro de um pipeline enxuto, com uma etapa de pré-processamento logo antes fornecendo texto bruto adicional. Juntos, esses componentes respondem a uma pergunta mais estreita do que "há quanto tempo está quieto?": isso soa como um pensamento completo, ou parece que ainda vem mais?

Um fragmento somado à sua continuação pode produzir uma decisão que o fragmento sozinho jamais produziria. Veja o exemplo abaixo:

O motor de IA está no centro da solução, mas não toma a decisão final sozinho. Ele produz um sinal, algo como "esta mensagem parece completa" ou "provavelmente vem mais", e outros componentes combinam esse sinal com regras adicionais: uma breve janela de espera após cada mensagem, reavaliação conforme novas mensagens chegam, um limite que impede o sistema de esperar indefinidamente e salvaguardas para o caso de o motor errar ou falhar. Em resumo: o motor interpreta a mensagem, e os componentes ao redor decidem quando agir.

Duas mensagens podem chegar tão próximas que a primeira é avaliada antes de a segunda entrar no sistema. Mesmo quando o motor determina que a primeira está completa, o sistema espera um instante antes de responder, dando tempo para outra que talvez já esteja a caminho. Se o motor dá timeout ou falha, o sistema espera em vez de adivinhar. A calibração segue o mesmo princípio: tratar por engano uma mensagem inacabada como completa deve ser mais raro do que esperar um pouco por uma que já estava pronta. Esse viés é intencional. Um silêncio a mais custa um instante; interromper um pedido inacabado pode custar a confiança de alguém. Sabemos qual dos dois podemos pagar.

As partes mais difíceis que o modelo

Três coisas acabaram importando mais do que acertar o motor de IA em si.

A velocidade real com que as pessoas digitam. Antes de fixar quanto tempo o timer de fallback deveria esperar, quisemos medir a cadência real de digitação em vez de chutar. Nossos próprios dados de produção eram o lugar errado para olhar, porque são autocensurados: uma continuação que chegaria poucos segundos depois já tinha recebido resposta no sistema antigo, então ela aparece como uma conversa nova, não como continuação. Para ter uma resposta honesta, voltamos aos logs de mensagens da nossa solução de WhatsApp, de antes de qualquer um desses limites existir, e medimos o intervalo real entre duas mensagens que a mesma pessoa mandou em sequência, sem nada no meio. Milhares de pares depois, o formato era inconfundível: quem divide um pensamento em várias mensagens quase sempre faz isso em rajada rápida, e a cauda afina depressa. É essa curva que define o timer de fallback, não a intuição.

Uma pessoa, muitos servidores. Um buffer que segura as mensagens de alguém enquanto esperamos para ver se vem mais não pode viver só na memória do servidor que por acaso atendeu, a partir do momento em que mais de uma cópia do serviço roda lado a lado. Duas mensagens enviadas com um piscar de diferença pela mesma pessoa podem cair em máquinas diferentes, cada uma convencida de que é a única cuidando daquela conversa, sem saber da outra. Então esse buffer vive em um armazenamento compartilhado que todos os servidores enxergam, em vez da memória de uma máquina. Assim, uma rajada da mesma pessoa sempre aterrissa no mesmo lugar, não importa qual máquina recebeu qual metade.

Lançar em um mercado sem dados próprios. Esse motor de IA aprendeu tudo o que sabe com conversas em português do produto original da Magie, o app de consumo que existiu antes de virarmos uma plataforma B2B: perto de 200 mil usuários e mais de 500 mil conversas únicas. Quando começamos o piloto com o banco no Peru, o idioma era outro, as gírias eram outras, e não havia uma única conversa peruana para treinar: um "Plin/Yape" onde esperávamos "Pix", soles onde esperávamos reais. Retreinar um modelo para um mercado em que mal havíamos lançado não era realista ainda, e esperar reunir conversas próprias significaria lançar sem detecção de turno nenhuma. Então aquele mercado roda com um modelo de linguagem, que raciocina diretamente sobre o pedido e sobre as capacidades reais do assistente em vez de casar padrões em um texto que nunca tinha visto. O que se transferiu foi a lição que o motor já havia nos ensinado no Brasil: um pedido soa terminado quando as peças de que ele precisa (destinatário, valor, chave) estão todas ali. Colocamos essa mesma ideia no modo como o modelo do Peru julga um pedido, mesmo que lá cada uma dessas peças seja outra. Custa mais por mensagem e ainda estamos fechando essa lacuna, mas significou não ter que escolher entre lançar no prazo e fazer isso direito.

As decisões de um modelo viram a entrada de todos os outros. O trabalho desse motor não termina em "espere" ou "responda agora": ele também decide onde cai a fronteira de um turno, ou seja, decide qual texto cada modelo à frente na cadeia realmente lê. Retreine-o, mexa no limiar, adicione um cliente cujos usuários digitam em outro ritmo, e o formato do que o classificador de intenção enxerga como uma mensagem pode mudar junto, sem ninguém tocar no código nem nos dados de treino daquele classificador. Pesquisadores do Google nomearam esse problema em 2015, no Hidden Technical Debt in Machine Learning Systems: dívida técnica oculta. Mudar um modelo de machine learning pode alterar silenciosamente aquilo com que todos os outros modelos do mesmo pipeline trabalham, de um jeito que nenhum code review pegaria. Software comum falha alto quando uma interface quebra. Um modelo apenas fica um pouco pior no que faz, em silêncio, até alguém notar os números derivando.

Onde isso está hoje

A evidência mais clara é um número que o sistema antigo jamais teria sido capaz de produzir. Na primeira semana desde que um banco no Peru entrou em produção, quatro em cada cinco mensagens avaliadas não precisaram esperar: o modelo de linguagem determinou “enviar agora” em 79,8% dos casos, um salto expressivo em relação ao sistema anterior, no qual todas as mensagens, sem exceção, eram obrigadas a aguardar por definição. Na semana analisada, chegaram a surgir cinco mensagens em um único turno de conversa no Brasil e seis em um turno no Peru.

Uma lição do Peru que levamos adiante: um classificador treinado não é algo que se produza no momento em que você precisa dele, exige conversas reais, semanas ou meses delas. Apostar nisso para um mercado ou uma funcionalidade que ainda não tem esse histórico é uma aposta perdida antes de começar. O manual agora é começar qualquer coisa nova com o que não exige treino nenhum, um modelo de linguagem raciocinando sobre o pedido, ou, se latência e custo ainda não importam, até o velho timer de janela fixa, mais tosco que os dois mas pronto no dia um, e só graduar para um classificador pequeno e rápido quando aquele mercado tiver produzido conversas suficientes para ensinar algo que valha a pena.

Esse período de espera também está encolhendo: um modelo de linguagem já consegue gerar um grande lote de conversas sintéticas plausíveis para preparar um classificador antes de ele ter pontuado uma única conversa real, algo que vale testar a sério, em vez de descartar por suposição. A mesma lógica valerá dentro da própria Magie conforme ela se divide em agentes especializados: um agente novo não precisa nascer com um classificador treinado, pode rodar no timer ou no caminho do modelo de linguagem desde o primeiro dia e só merecer um dedicado depois de ter atendido conversas reais suficientes. Ao mesmo tempo, podemos chegar a SLMs tão bons e rápidos que, para alguns países, nenhum modelo de ML seria necessário.

O caminho daqui tem duas camadas. A mais próxima já está em curso: a Magie está se dividindo de um grande assistente em vários especializados, cada um dono da sua fatia, e a detecção de turno vai junto com eles em vez de continuar centralizada. O assistente que cuida do seu pagamento decide sozinho quando você terminou uma frase sobre pagamentos, independentemente do que o assistente de investimentos esteja fazendo no mesmo instante.

A mais distante é uma direção, não uma funcionalidade entregue: um agente que lembra como você especificamente fala com ele, hiperpersonalização, em vez de um agente ajustado por organização.

Este é o primeiro de uma série de posts sobre como a Magie constrói esses agentes. Os próximos vão mais fundo em engenharia de contexto, hiperpersonalização, memória e em antecipar o que você precisa antes de você pedir.