Integrar LLMs con sistemas de negocio: WhatsApp, pagos y POS
Un modelo útil termina tocando WhatsApp, un cobro o una caja. Esta página cuenta cómo resolví esas integraciones en AgendaGo y en Bonuxo, los dos en producción, y dónde interviene el modelo y dónde no.
Qué es y qué lo vuelve difícil
Conectar un LLM con sistemas de negocio es hacer que lo que el modelo decide termine en un canal o en una operación real: un mensaje de WhatsApp, una suscripción cobrada, una venta en una caja. Lo difícil no es la llamada al modelo sino lo que la rodea: ventanas y plantillas del canal, eventos duplicados o fuera de orden, límites de tasa y operaciones que no se pueden repetir.
AgendaGo: el agente de WhatsApp (en producción)
- Todo lo que sale hacia el cliente pasa por una única vía de envío, que aplica la ventana de 24 horas y las plantillas de WhatsApp. El modelo no manda mensajes por su cuenta.
- Reservar pasa por tres barreras: el horario sale del motor de disponibilidad en el mismo turno, el cliente no puede tener otra reserva ese día y un trigger de la base bloquea el sobreturno.
- Un router determinista responde alrededor del 44% de los mensajes sin llamar al modelo.
- La app pasó la revisión de Meta el 31 de agosto de 2026. AgendaGo integra además MercadoPago.
Bonuxo: POS, e-commerce y cobros (en producción)
En Bonuxo la integración con sistemas de negocio la construí en producción, pero no pasa por un modelo: el LLM de Bonuxo es Nux, que está en construcción y apagado en producción. Lo que sigue es la base sobre la que un agente podría operar.
- API para POS con claves live y test (solo se guarda el hash SHA-256), límites por clave y por IP, Idempotency-Key opcional con retención de 24 horas y ventas exactly-once. Contrato OpenAPI 3.0.3, versión 1.3.0.
- Integraciones verificadas en el código con Fudo (POS), TiendaNube (e-commerce) y un adaptador de MercadoPago POS, con polling y reconciliación.
- Cobro recurrente con MercadoPago: firma del webhook verificada con HMAC-SHA256 en tiempo constante, reclamo idempotente en dos fases y manejo de eventos duplicados y fuera de orden.
- Una prueba de carga contra producción, el 30 de septiembre de 2026, con 3084 solicitudes y 0 errores; encontró que el límite por clave no se aplicaba, y lo corregí.
La decisión de fondo
En los dos proyectos el canal lo controla código determinista, no el modelo: una vía única de envío en WhatsApp, y idempotencia y reconciliación en los cobros. Es más código por integración, a cambio de que un error del modelo no pueda duplicar un cobro ni romper la ventana de un canal.
Stack relacionado
- WhatsApp Cloud API
- MercadoPago
- Fudo
- TiendaNube
- OpenAPI
- Supabase Edge Functions
- .NET 8