Un agente de IA para WhatsApp es un modelo de lenguaje conectado a un número o grupo de WhatsApp que lee mensajes, decide qué hacer y actúa por medio de herramientas: responde desde una base de conocimiento, abre un ticket, actualiza un CRM o le pasa la conversación a una persona. La demo se arma en una tarde. Lograr que no te haga pasar vergüenza frente a un cliente toma bastante más.
Tenemos varios funcionando. Un agente que mantiene al día un CRM a partir del grupo de WhatsApp que compartimos con un socio. Un flujo de entrada que lee los grupos de WhatsApp de cada cliente y propone tickets de soporte. Un asistente de borradores en una bandeja de soporte, que escribe notas privadas que luego envía una persona. Un agente de solicitudes del equipo que responde desde la wiki de la empresa y no publica nada sin aprobación. Y ChatWise, nuestro producto de chat de soporte, que responde en un widget web y en WhatsApp a partir del contenido propio de cada negocio y le pasa la conversación a una persona cuando corresponde.
Los modos de fallo que siguen tienen algo en común: el agente hace algo que el prompt le prohíbe de manera explícita. Esa es la lección principal, así que va primero: una regla que solo vive en el prompt no es una regla. Cada sección explica cómo ocurre el fallo, por qué, y el arreglo que se sostiene en el código.
1. El bucle de eco en un grupo compartido
Cómo puede fallar. Un agente publica una respuesta en un grupo de WhatsApp que comparte con otras personas. WhatsApp le devuelve ese mensaje al agente como un mensaje entrante nuevo, con el grupo como remitente en lugar del número del agente, así que una verificación ingenua de “¿esto lo enviamos nosotros?” no lo detecta. El agente se responde a sí mismo. Si además el entorno de ejecución corre las llamadas a herramientas en paralelo y la marca de “ya enviado” se activa después del envío, un solo turno puede publicar varias veces.
Qué cuesta. Una ráfaga de mensajes frente a todos los miembros del grupo, más efectos que el prompt prohíbe. Por ejemplo, reuniones escritas en el CRM que nadie agendó, o un seguimiento cerrado que nadie pidió cerrar.
La solución.
- Tratar “el remitente es el propio grupo” como un mensaje del agente.
- Reservar el único espacio de envío de forma atómica antes de enviar: un envío por turno, impuesto en el código.
- Un cortacircuitos: la bandeja rechaza todo lo que pase de 8 mensajes en una ventana móvil de 60 segundos, así que un bucle se agota en segundos y no en minutos.
- No darle al agente una herramienta que cierre registros. Que el agente agregue; que cierre una persona.
2. El agente encuentra la respuesta y no se la dice a nadie
Cómo puede fallar. El agente razona bien, escribe la respuesta como texto plano y termina su turno. En una terminal, eso es una respuesta. En una integración con WhatsApp, termina en un log que nadie lee.
La solución. Cada turno debe terminar con una de dos herramientas explícitas: responder en el grupo o no hace falta responder. Si el modelo termina un turno sin llamar a ninguna, el entorno de ejecución le da un empujón una sola vez, protegido por una marca para que ese empujón no pueda entrar en bucle. Los turnos perdidos se registran con su propia etiqueta para poder contarlos.
3. Una fecha de vencimiento de hace años
Cómo puede fallar. Pídele a un agente que registre una factura pendiente con una fecha de vencimiento razonable y puede fijarla años en el pasado. Los modelos no saben qué día es hoy; lo adivinan a partir de sus datos de entrenamiento.
La solución. Cada mensaje que ve el agente lleva como prefijo la fecha real, el día de la semana y la zona horaria local. Con eso, “llámalos el lunes” se resuelve en el lunes correcto. Es una línea de código y debería estar en cada agente que construyas.
4. Un ID que no existe
Cómo puede fallar. El modelo informa un ID creíble en lugar del que devolvió la herramienta. Por ejemplo, el agente crea el seguimiento número 4 y luego le confirma al grupo que creó el “seguimiento 14”. Un número creíble, equivocado, y ya por escrito frente a todos los miembros del grupo.
La solución. La capa de herramientas registra cada ID que las herramientas devolvieron de verdad durante el turno. La herramienta de respuesta rechaza cualquier mensaje que cite un ID fuera de ese conjunto. Hay que registrar con amplitud y comparar con rigor: un rechazo falso deja al agente sin poder responder, y eso es peor de lo que parece cuando alguien está esperando.
5. El cliente correcto, la conversación equivocada
Cómo puede fallar. Un mismo cliente puede tener varios grupos de WhatsApp. Llega un reporte en el segundo grupo, y un flujo de entrada que asocia por cliente lo vincula a un ticket abierto del primer grupo. Toma el camino de “seguimiento”, y si los seguimientos no envían acuse de recibo, el cliente no recibe ninguna respuesta.
La solución. Asociar por canal, no solo por cliente. La regla general: cuando una misma identidad puede tener varios canales, limita cada búsqueda al canal del que vino el mensaje.
6. Al ocultar los mensajes del agente, se ocultan también los de una persona
Cómo puede fallar. El arreglo obvio para los ecos es descartar todos los mensajes enviados desde el número del agente. Pero muchas veces una persona también escribe a mano desde ese mismo número. El agente pierde el contexto de una respuesta humana, interpreta por su cuenta el mensaje siguiente y actúa, por ejemplo creando un cliente con identificación fiscal “1”.
La solución.
- Los mensajes de la línea compartida le llegan al agente como contexto etiquetado, en lugar de descartarse.
- Las publicaciones del propio agente se escriben en un registro de enviados antes de enviarse, para que un eco nunca pueda llegar antes que el registro de lo que se envió. Ese registro es lo que distingue “esto lo dijo el agente” de “esto lo dijo una persona”.
- A las personas se las identifica por número de teléfono, nunca por nombre visible.
- La herramienta de creación de clientes rechaza nombres de miembros del grupo e identificaciones fiscales de menos de seis caracteres.
7. Un prompt no es un sandbox
Qué vigilar. Esto aplica a cualquier agente de chat, sea de WhatsApp o del chat del equipo. Si un puente de terceros pasa su clave de publicación al entorno del agente y el runtime del agente tiene acceso a una shell, cualquier instrucción que el modelo siga, incluida una escondida en un mensaje, puede llegar a esa clave.
La solución. Aislamiento a nivel de sistema operativo: el agente corre sin entorno heredado, con un sistema de archivos de solo lectura y una lista de red permitida. La clave vive con un usuario de servicio separado, y el agente solo llega a ella mediante herramientas acotadas sobre un socket local. Usa un entorno de ejecución que imponga por sí mismo una lista de herramientas permitidas, en lugar de confiar en que el modelo la respete.
8. “Ya le avisamos al equipo”, sin que nadie avisara
Cómo puede fallar. Este es universal: le pasa a cualquier agente que actúa y después informa, en WhatsApp o en cualquier otro canal. Por ejemplo, un agente integra un cambio de un cliente, lo sube y recién después construye el sitio. La construcción falla. Aun así, el agente le dice al cliente “le avisamos al equipo”, y no se envió nada. Los cambios que venían detrás del que se rompió pueden fallar junto con él.
La solución. Construir antes de integrar, para que un cambio roto nunca llegue. Confirmarle al usuario solo después de que el efecto haya ocurrido, y hacer que cada fallo deje un rastro que se pueda buscar, haya o no algo más configurado.
Los patrones que aplicamos desde el primer día
- Herramientas acotadas, impuestas por el entorno de ejecución. La herramienta de envío no tiene parámetro de destinatario; a dónde envía queda fijo en la configuración.
- Un trabajo a la vez, sesión nueva por mensaje. La bandeja escribe cada trabajo en un archivo y responde de inmediato. Cada sesión empieza limpia, más un fragmento corto y etiquetado del historial reciente, así que nada se desvía arrastrando horas de contexto.
- Límites de tasa y un envío por turno. Son baratos y convierten un bucle en una línea de log en lugar de un incidente.
- Registros antes de los efectos. Anota lo que estás por enviar y después envíalo.
- Las personas cierran, los agentes agregan. Nuestra regla: los agentes pueden crear tickets, seguimientos y borradores, y cerrar, borrar y facturar sigue en manos de personas. En nuestros agentes de WhatsApp, eso lo garantizan las herramientas que reciben.
- El traspaso a una persona como ruta de primera clase. En ChatWise, un enrutador elige entre responder desde la base de conocimiento, usar una herramienta o escalar a una persona, con un motivo y un puntaje de confianza. El traspaso solo ocurre cuando el cliente pide de forma explícita hablar con alguien, y una segunda verificación lo confirma antes de seguir. Una persona también puede pasar la conversación a modo manual, donde la IA se queda callada.
- Una evaluación definida antes del lanzamiento. Casos en cada idioma que habla el agente, que cubren inyección de prompts, negarse a inventar precios, errores de herramientas reportados con honestidad y cambios de idioma a mitad de la conversación, con la meta fijada antes de la primera corrida y ningún fallo permitido en los casos de seguridad.
- Planea para la API oficial. Nuestra recomendación para todo lo que vea el cliente es la WhatsApp Business Cloud API. Los clientes no oficiales son más baratos para empezar, pero corren el riesgo de que Meta bloquee el número, así que diseñamos el transporte como una pieza reemplazable de la que el agente no depende.
Por dónde empezar
Si vas a llevar la atención al cliente con IA a WhatsApp, empieza con un alcance acotado: que responda desde tu propio contenido y pase todo lo demás a una persona. Activa el traspaso a una persona antes de que la IA responda su primer mensaje, no después de la primera queja. Decide pronto qué debe recordar el agente entre conversaciones. Y da por hecho que todo lo que solo escribiste en el prompt va a terminar pasando de todos modos.
Así construimos ChatWise y los agentes a medida que entregamos a nuestros clientes. Si quieres uno para tu negocio, hablemos.
Preguntas frecuentes
¿Qué es un agente de IA para WhatsApp?
Un agente de IA para WhatsApp es un modelo de lenguaje conectado a un número o grupo de WhatsApp que lee los mensajes, decide qué hacer y actúa por medio de herramientas: responde desde una base de conocimiento, crea un ticket, actualiza un CRM o le pasa la conversación a una persona. A diferencia de un chatbot de WhatsApp con guion fijo, el agente decide qué herramienta usar en cada mensaje.
¿Puede un agente de IA encargarse solo de la atención al cliente en WhatsApp?
Puede responder preguntas rutinarias a partir de tu propio contenido, pero debe pasarle la conversación a una persona cuando la solicitud se sale de su alcance, cuando el cliente pide hablar con alguien o cuando parece frustrado. En nuestras implementaciones, el agente responde dentro de un alcance acotado o escribe un borrador que una persona aprueba antes de que llegue al cliente.
¿Por qué los agentes de IA en WhatsApp envían mensajes duplicados o en bucle?
Por lo general, porque el agente vuelve a leer sus propios mensajes como si fueran nuevos, o porque llama a la herramienta de envío varias veces en un mismo turno. Las instrucciones del prompt no lo evitan. La solución está en el código: filtrar los mensajes del propio agente, permitir un solo envío por turno y agregar un cortacircuitos que detenga al agente cuando supere una tasa de mensajes.
¿Conviene usar la WhatsApp Business API oficial o un cliente no oficial?
Para todo lo que vea el cliente, usa la WhatsApp Business Cloud API oficial. Los clientes no oficiales son más baratos para empezar, pero corren el riesgo de que Meta bloquee el número. Diseña el transporte como una pieza reemplazable para poder cambiarlo sin tocar el agente.
¿Cómo evitas que un agente de IA invente información?
No confíes en el prompt. Dale al agente sus datos por medio de herramientas, registra cada ID y cada valor que las herramientas devolvieron de verdad, y haz que la herramienta de respuesta rechace los mensajes que citen cualquier otra cosa. Inyecta la fecha de hoy en cada mensaje, y deja que el agente cree registros pero exige que sea una persona quien los cierre o los borre.