Integrar LLMs com sistemas de negócio: WhatsApp, pagamentos e POS
Um modelo útil acaba tocando o WhatsApp, uma cobrança ou um caixa. Esta página conta como resolvi essas integrações no AgendaGo e no Bonuxo, os dois em produção, e onde o modelo intervém e onde não.
O que é e o que a torna difícil
Conectar um LLM a sistemas de negócio é fazer com que o que o modelo decide termine num canal ou numa operação real: uma mensagem de WhatsApp, uma assinatura cobrada, uma venda num caixa. O difícil não é a chamada ao modelo, e sim o que a cerca: janelas e templates do canal, eventos duplicados ou fora de ordem, limites de taxa e operações que não podem ser repetidas.
AgendaGo: o agente de WhatsApp (em produção)
- Tudo o que sai para o cliente passa por uma única via de envio, que aplica a janela de 24 horas e os templates do WhatsApp. O modelo não manda mensagens por conta própria.
- Reservar passa por três barreiras: o horário sai do motor de disponibilidade no mesmo turno, o cliente não pode ter outra reserva no dia e um trigger do banco bloqueia o overbooking.
- Um router determinístico responde cerca de 44% das mensagens sem chamar o modelo.
- O app passou pela revisão da Meta em 31 de agosto de 2026. O AgendaGo integra também o MercadoPago.
Bonuxo: POS, e-commerce e cobranças (em produção)
No Bonuxo, a integração com sistemas de negócio eu construí e está em produção, mas ela não passa por um modelo: o LLM do Bonuxo é o Nux, que está em construção e desligado em produção. O que segue é a base sobre a qual um agente poderia operar.
- API de POS com chaves live e test (só o hash SHA-256 é guardado), limites por chave e por IP, Idempotency-Key opcional com retenção de 24 horas e vendas exactly-once. Contrato OpenAPI 3.0.3, versão 1.3.0.
- Integrações verificadas no código com Fudo (POS), TiendaNube (e-commerce) e um adaptador de MercadoPago POS, com polling e reconciliação.
- Cobrança recorrente com MercadoPago: assinatura do webhook verificada com HMAC-SHA256 em tempo constante, reivindicação idempotente em duas fases e tratamento de eventos duplicados e fora de ordem.
- Um teste de carga contra a produção, em 30 de setembro de 2026, com 3084 requisições e 0 erros; ele encontrou que o limite por chave não estava sendo aplicado, e corrigi isso.
A decisão de fundo
Nos dois projetos o canal é controlado por código determinístico, não pelo modelo: uma via única de envio no WhatsApp, e idempotência e reconciliação nas cobranças. É mais código por integração, em troca de que um erro do modelo não consiga duplicar uma cobrança nem quebrar a janela de um canal.
Stack relacionado
- WhatsApp Cloud API
- MercadoPago
- Fudo
- TiendaNube
- OpenAPI
- Supabase Edge Functions
- .NET 8