Aberto a posições de AI Engineer remoto ou híbrido
Competência

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.

Onde a apliquei

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