Agente de WhatsApp con IA: arquitectura, costos y límites reales

Poner un agente de IA en WhatsApp es la petición más común de cualquier negocio que ya vive en el chat. También es la más subestimada: WhatsApp no es un canal abierto como Telegram, sino una plataforma comercial con reglas de mensajería, plantillas aprobadas y un precio por mensaje que depende del país del cliente. Esta guía te da la arquitectura real —Cloud API directo vs proveedores como Twilio o 360dialog—, los costos por conversación, los límites de plantillas y la alternativa honesta: empezar en Telegram.

Cómo funciona WhatsApp Business Platform

La pieza central es la Cloud API de Meta: un API HTTP que recibe y envía mensajes de WhatsApp. Cuando un cliente escribe a tu número, Meta hace una petición HTTP a tu servidor (webhook). Tu servidor procesa el mensaje —aquí entra tu agente de IA— y responde llamando al API con el mensaje de salida.

La arquitectura mínima de un agente:

1. Número de WhatsApp conectado a un Meta Business Account.
2. Webhook propio (endpoint HTTPS público) donde Meta envía los mensajes entrantes.
3. Capa de agente: modelo de lenguaje + herramientas, que decide la respuesta.
4. Llamada de salida al Cloud API con el texto o plantilla a enviar.

En el handshake GET, compara hub.verify_token con el secreto de verificación que configuraste y comprueba hub.mode=subscribe; si coincide, devuelve el valor de hub.challenge como texto, no el token. Para los POST, valida la firma sobre los bytes originales antes de interpretar JSON. Los eventos pueden contener mensajes o estados: no asumas que siempre existe texto. Persiste los mensajes válidos en una cola durable antes de responder 200 y procesa después con idempotencia.

Cloud API directo vs proveedores

Criterio	Meta Cloud API directo	Twilio / 360dialog (BSP)
Precio	Tarifa por mensaje de Meta	Tarifa de Meta + margen del proveedor
Setup	App en Meta for Developers, verificación de negocio	Cuenta del proveedor, suelen acelerar onboarding
Soporte técnico	Comunidad y docs; sin soporte directo en planes gratis	Soporte del proveedor, SLAs en planes pagos
Control	Total: datos y webhooks directos	Pasan por la infraestructura del proveedor
Para quién	Desarrolladores con tiempo de integración	Equipos que necesitan soporte y velocidad

Los proveedores no eliminan el costo de Meta: lo agregan. La pregunta no es "¿Twilio o Meta?" sino "¿cuánto vale tu tiempo de integración y tu necesidad de soporte?". Para un MVP con criterio técnico propio, el Cloud API directo alcanza; para operaciones serias con SLAs, un BSP se paga solo.

Costos reales por conversación

Meta cobra por mensaje entregado, no por conversación como antes. Dos reglas que definen tu presupuesto:

• Ventana de atención de 24 horas: los mensajes libres de servicio y las plantillas de utilidad entregadas dentro de esa ventana son gratuitos según las condiciones de Meta. No todas las plantillas tienen el mismo tratamiento.
• Fuera de la ventana: utiliza plantillas aprobadas; las categorías de plantilla son utilidad, marketing y autenticación. El cargo depende de categoría, mercado, volumen y excepciones aplicables. Los puntos de entrada gratuitos pueden abrir otra ventana con condiciones específicas; consulta la tabla vigente.

El precio varía por país y categoría: una plantilla de utilidad cuesta menos que una de marketing, y el mismo mensaje cuesta distinto en Estados Unidos que en América Latina. La documentación de precios de Meta publica las tablas por código de país; antes de estimar tu agente, busca el país de tus clientes y multiplica por la cantidad de mensajes de plantilla que enviarás al mes.

A esto súmale los tokens del modelo (la conversación con tu agente), el hosting de tu webhook y, si usas BSP, el margen del proveedor. La fórmula de costo mensual:

Costo = (plantillas entregadas × tarifa del país) + tokens del modelo + hosting

Para un agente de soporte que solo responde dentro de la ventana de 24 horas, el costo por mensaje puede ser casi cero. Para campañas proactivas, el costo lo domina la tarifa de plantillas de marketing.

Límites de plantillas y reglas de producto

• Aprobación previa: cada plantilla proactiva pasa por revisión de Meta; cambios de copy requieren nueva aprobación.
• Ventana de sesión: una vez que el cliente escribe, tienes 24 horas de conversación libre de plantillas.
• Calidad del número: reportes de usuarios o mensajes marcados bajan tu límite de mensajes por día.
• No hay spam: enviar sin opt-in o con contenido engañoso es la vía rápida a un bloqueo de número.

Para un agente con IA, la consecuencia práctica: el agente debe responder dentro de la ventana de 24 horas y nunca iniciar conversación sin plantilla aprobada. Tu prompt y tus herramientas deben asumir ese límite como una regla de negocio, no como un detalle técnico.

Alternativa para empezar: Telegram

Si el objetivo es validar el agente —no el canal—, Telegram es objetivamente más simple:

• Bot API gratuito, sin aprobación de plantillas ni costo por mensaje.
• El mismo webhook HTTPS, con verificación por token de tu parte.
• Soporta botones, encuestas y archivos nativos, ideales para agentes ricos.
• Migrar el backend después es directo: el agente (LLM + herramientas) no cambia, solo cambia el adaptador de mensajería.

La estrategia recomendada: construye el agente contra Telegram, valida que resuelve el problema con tus clientes reales, y solo entonces invierte en el onboarding de WhatsApp. El trabajo de arquitectura (agente, herramientas, memoria) se reutiliza casi completo, como explica la guía de despliegue de agentes en WhatsApp, Telegram y Slack. Y antes de elegir modelo o arquitectura, revisa la comparativa de costos y latencia de agentes de mensajería para no descubrir el precio cuando ya tienes tráfico.

Laboratorio local: challenge y firma sin enviar mensajes

Descarga verificar-whatsapp.mjs. Contiene dos funciones para Node.js 20 o posterior: validar el desafío GET y verificar HMAC-SHA256 del POST con comparación de tiempo constante. Es para Meta Cloud API directa, no para la firma de Twilio. No crea un servidor, no envía mensajes ni necesita una cuenta para probar la lógica.

Desde la carpeta descargada puedes comprobar el handshake:

node --input-type=module -e 'import {desafioMeta} from "./verificar-whatsapp.mjs"; const q=new URLSearchParams({"hub.mode":"subscribe","hub.verify_token":"demo","hub.challenge":"123"}); console.log(desafioMeta(q,"demo"))'

La salida esperada es 123. Si el token o el modo son incorrectos devuelve null; tu handler debe traducirlo a rechazo HTTP. El verify token es un secreto elegido para el handshake; el app secret es otra credencial y se usa para la firma de eventos. No los intercambies.

Para integrar la firma, conserva el cuerpo como Buffer antes de llamar a JSON.parse. Firma y compara esos bytes: parsear y volver a serializar puede cambiar espacios u orden y producir una firma distinta. Aplica también un límite de tamaño al body en el servidor.

Prueba de desarrollo	Resultado esperado
Challenge con token válido	Texto exacto del challenge
Token incorrecto	Rechazo, sin revelar el secreto
Body original y firma correcta	Aceptar validación criptográfica
Un byte del body modificado	Rechazar
Cabecera ausente o hexadecimal mal formado	Rechazar sin excepción
Misma firma y mismo evento repetidos	Firma válida, pero deduplicar por ID de evento/mensaje

La firma autentica el body; no evita replay ni reemplaza deduplicación. Tampoco demuestra que el remitente esté autorizado para consultar un pedido. Resuelve los permisos del negocio después de autenticar el evento y antes de llamar herramientas.

Estado mínimo para no responder dos veces

Guarda el ID del mensaje entrante, cuenta/canal, estado de procesamiento y un ID de tarea. Una restricción única debe resolver dos recepciones concurrentes: consultar primero si existe y luego insertar sin protección deja una carrera.

Para un timeout del envío saliente, conserva estado “resultado desconocido” y concilia con el proveedor. No ejecutes automáticamente otra compra o reembolso porque falló el envío de la confirmación. La lógica sensible debe seguir el contrato de herramientas con aprobación.

Alcance verificado: las funciones de challenge y firma se prueban localmente con secretos ficticios y cuerpos sintéticos. Onboarding, verificación empresarial, aprobación de plantillas y entrega de mensajes reales dependen de tu cuenta y no se presentan como realizados aquí. Comprueba además que tu caso de uso cumple las políticas vigentes de WhatsApp; acceso técnico no implica permiso para cualquier asistente de IA.

Checklist para el día uno

1. Compara el token de verificación y devuelve hub.challenge; valida después las firmas de los POST.
2. Maneja el payload entrante con ID de mensaje único (idempotencia).
3. Respeta la ventana de 24 horas: responde dentro de sesión.
4. Usa plantillas aprobadas para todo mensaje proactivo.
5. Estima el costo con la tabla de precios del país de tus clientes.
6. Registra cada mensaje con traceId para auditar decisiones del agente.

WhatsApp te da el canal donde ya están tus clientes; el Cloud API te da el acceso; y tu agente es lo único que diferencia tu respuesta de la de un bot de menú. Construye el agente bien —con permisos, memoria y observabilidad— y el canal solo será un adaptador más. El hub de construcción de agentes tiene el resto del camino: arquitectura, herramientas y despliegue. Si estás arrancando desde cero, el curso gratuito te muestra cómo instalar y operar tu propio agente antes de atarte a un canal específico.