--- title: "Cómo llevar un agente de IA a producción en WhatsApp (WABA en la práctica)" description: "La guía directa de quien ya lo hizo: desde la WhatsApp Business API hasta la ventana de 24h, plantillas HSM, fallback de LLM y lo que separa un bot de demo de un agente que aguanta producción." slug: agente-ia-whatsapp-producao lang: es date: 2026-07-22 updated: 2026-07-22 author: Lucas Silva category: deep-dive tags: [WhatsApp, WABA, Agentes de IA, IA Conversacional, Producción, LLM] reading_time: 12 featured: true --- La mayoría de los "agentes de IA en WhatsApp" que veo por ahí nunca salen de la demo. Funcionan en el video de LinkedIn, responden bien en el ambiente controlado, y se caen en el primer contacto con un cliente real. Este post es lo contrario de eso: es lo que aprendí poniendo agentes de verdad en producción, atendiendo, vendiendo y resolviendo las 24 horas del día. Si quieres un bot para postear, no hace falta que leas. Si quieres un agente que aguante producción, presta atención que ahí va. ## Antes que nada: necesitas la WABA, no el WhatsApp común Existe una diferencia que tumba al 90% de los proyectos apenas empiezan. El WhatsApp que usas en el celular, e incluso el **WhatsApp Business** de la app, no está hecho para automatización a escala. La herramienta correcta es la **WhatsApp Business API (WABA)**, la API oficial de Meta. Con la WABA ganas tres cosas que no existen en la app: - **Envío y recepción programáticos** vía webhook y endpoints REST, sin depender de un celular encendido. - **Múltiples agentes y automatización** en el mismo número, sin la limitación de sesión única. - **Plantillas aprobadas** para iniciar conversaciones de forma legítima (más sobre esto en un momento). El camino no oficial —librerías tipo Baileys que emulan el WhatsApp Web— funciona para un prototipo, pero es una bomba de tiempo: baneo del número, se rompe con cada actualización del protocolo, cero garantía. Para cualquier cosa seria, es WABA. Punto. ## La ventana de 24 horas: la regla que más gente ignora Aquí está el concepto que separa a quien entiende de quien apenas leyó la documentación por encima. Meta divide los mensajes en dos mundos: 1. **Dentro de la ventana de 24h** — después de que el *cliente* te manda un mensaje, se abre una ventana de 24 horas en la que puedes responder libremente, con texto, multimedia, lo que quieras. Es la conversación "de servicio". 2. **Fuera de la ventana** — ¿pasaron 24h sin mensaje del cliente, o quieres ser el primero en hablar? Ahí **solo puedes** iniciar con una **plantilla aprobada** (HSM — Highly Structured Message). Ignorar esto es la causa número 1 de "mi mensaje no llega". No es un bug, es una regla. Tu agente necesita saber en qué estado está la conversación y elegir entre respuesta libre y plantilla, automáticamente. En la práctica, modelo esto como una máquina de estados simple por contacto: ``` NUEVA → solo la plantilla puede abrir ABIERTA_24H → respuesta libre habilitada (guardo el timestamp del último msg del cliente) EXPIRADA → volvió a plantilla ``` Cada mensaje recibido en el webhook renueva el `timestamp`. Antes de cualquier envío proactivo, verifico la ventana. Simple, pero es lo que mantiene la operación viva. ## Plantillas HSM: donde la burocracia se encuentra con la conversión Toda plantilla que inicia una conversación necesita ser **aprobada por Meta** antes de correr. Tienen categorías (marketing, utility, authentication) y la categoría cambia el precio y la tolerancia al rechazo. Lo que aprendí a los golpes: - **Escribe la plantilla pensando en la aprobación, no solo en el cliente.** Una promesa vaga, un disparador de urgencia exagerado y un "clic aquí" suelto tumban la aprobación. Una utility bien escrita pasa fácil. - **Las variables son posicionales** (`{{1}}`, `{{2}}`). Documenta qué significa cada una en tu código, porque seis meses después no te vas a acordar. - **Ten fallback de plantilla.** Si una plantilla se pausa por calidad, tu operación no puede parar. Yo mantengo variaciones aprobadas de reserva. La calidad del número (el famoso *quality rating* verde/amarillo/rojo) sube y baja según los clientes marquen como spam o bloqueen. Una plantilla mala tumba el rating, un rating malo tumba el límite de envío. Es un ciclo, y te obliga a ser relevante. ## La arquitectura mínima de un agente que aguanta producción Un agente de WhatsApp que funciona de verdad no es "webhook → OpenAI → respuesta". Esa versión ingenua se rompe con el primer cliente que manda tres mensajes seguidos, un audio y una foto. La arquitectura real tiene capas: **1. Ingesta (webhook)** Recibe el payload de Meta, valida la firma y —esto es crucial— **responde 200 al instante**. El procesamiento es asíncrono, en una cola. Si procesas de forma síncrona, Meta reenvía el webhook creyendo que falló, y procesas el mismo mensaje dos veces. **2. Normalización** Texto, audio, imagen, documento, ubicación, botón presionado: todo se convierte en un formato interno único. El audio pasa por transcripción (STT) antes de llegar al LLM. El agente no debería saber ni importarle si el origen fue voz o texto. **3. Agregación de mensajes (debounce)** Un cliente real no manda un párrafo. Manda "hola", después "quería saber", después "sobre el plan de ustedes": tres webhooks en cinco segundos. Si respondes a cada uno, el agente parece un esquizofrénico. Yo junto los mensajes en una ventana corta (unos 3–8 segundos de silencio) antes de accionar el LLM. Cambia todo en la naturalidad. **4. El cerebro (LLM + contexto + herramientas)** Aquí vive la inteligencia: el historial de la conversación, los datos del cliente (del CRM/ERP) y las **herramientas** que el agente puede llamar: consultar un pedido, abrir un ticket, agendar una visita. El LLM no *es* el producto; es el orquestador que decide qué herramienta usar. **5. Entrega** Elige ventana vs. plantilla, respeta los rate limits y registra todo. El estado (enviado/entregado/leído/fallido) vuelve por webhook y alimenta la lógica. ## Fallback de LLM: el día que el proveedor se cae (y se cae) Si tu agente depende de un único proveedor de LLM, tiene la disponibilidad del eslabón más débil. Los proveedores se caen, se ponen lentos, retornan error 529. En producción, con clientes esperando respuesta en segundos, eso es inaceptable. Yo corro con **fallback en cascada**: un modelo primario, y si falla o supera el timeout, cae automáticamente al secundario, después al terciario, de proveedores distintos. El cliente nunca se entera. La regla es: *ningún punto único de falla en la respuesta*. Esto también me da libertad para optimizar costo: modelo más barato para intenciones simples, modelo más capaz solo cuando la conversación exige razonamiento. La mayor parte de los mensajes es "¿cuál es mi factura?": no hace falta el modelo tope de gama para eso. ## Herramientas (tools): donde el agente deja de ser charla y se vuelve producto Un agente que solo conversa es un chatbot mejorado. Un agente que **actúa** es software. La diferencia son las herramientas. En mi call center de IA para proveedores de internet (ISP), el agente no "habla sobre" la segunda copia de la factura: **consulta el ERP, genera la factura y manda el PIX** dentro de la conversación. No "explica cómo abrir un ticket": lo **abre**. Esto exige conectar el LLM a las APIs reales del negocio (CRM, ERP, gateway de pago) vía function calling, con validación rigurosa de cada llamada. Regla de oro: **toda herramienta que cambia estado en el mundo real necesita confirmación explícita y log.** El LLM puede alucinar; la capa de herramientas no puede. Valida, confirma con el cliente cuando el paso es irreversible, y registra todo. ## Lo que separa demo de producción: el resumen honesto - **Idempotencia:** el mismo mensaje va a llegar dos veces. Manéjalo por `message_id`. - **Observabilidad:** si no registras cada decisión del agente, no depuras nada. Correlation ID por conversación, del webhook a la respuesta. - **Human handoff:** el agente necesita saber cuándo pasar a un humano, y pasar con el contexto entero, no lanzando al cliente al inicio. - **Costo por conversación:** mídelo. Un agente descontrolado llamando al modelo caro en loop quema el presupuesto sin que lo veas. - **Resiliencia:** cola, retry, fallback. Producción no perdona el "ah, el proveedor se cayó". ## Empieza por el problema, no por la tecnología El error más común no es técnico. Es construir el agente antes de saber qué resuelve. Yo siempre empiezo por la pregunta: *¿qué conversación, repetida mil veces por mes, está consumiendo al equipo humano?* Es ahí donde la IA se paga sola. Segunda copia de la factura, estado de un pedido, agendamiento, duda recurrente. Automatiza la conversación que ya ocurre, no la que imaginas que va a ocurrir. Un agente de WhatsApp en producción no es un proyecto de IA. Es un producto de negocio que da la casualidad de usar IA en el núcleo. Trátalo así y va a producción. Trátalo como demo y se queda en la demo. --- *Construyo agentes de IA y productos conversacionales en producción, del diagnóstico al deploy. Si tienes una operación en WhatsApp que necesita escalar sin contratar más gente, [escríbeme](https://www.lucassilva.io).*