Traspaso de IA a humano en bots de WhatsApp con Flex

Introducción

El 90% de los bots de WhatsApp que audito tienen la misma falla. El agente de IA le dice al usuario que su conversación se está transfiriendo a una persona. Y después no pasa nada. El usuario sigue escribiendo. La IA sigue respondiendo. En algún momento se da cuenta de que la "transferencia" era mentira, se frustra y se va. Perdiste un cliente potencial por un if que falta.

Esto no es un problema de prompt engineering. Es un problema de arquitectura. A la IA nunca la cablearon para transferir nada. Solo dijo que lo iba a hacer.

Armé un sistema que lo resuelve con N8N como capa de orquestación, Claude Sonnet como modelo y Twilio Flex como plataforma de agentes humanos. El objetivo: la IA maneja el 80% de las conversaciones sola. El 20% restante, quejas sensibles, preguntas fuera de alcance y pedidos explícitos de hablar con alguien, se escala con todo el historial intacto.

Acá va cómo funciona la arquitectura y qué le cambiaría.

Cómo está estructurado el flow

Cuando entra un mensaje, Twilio lo captura y lo despacha a un webhook que apunta a un flow de N8N. Lo primero que hace el flow es extraer el payload del mensaje (from, to, body, context) y traer el estado actual de la conversación.

El estado de la conversación es la estructura de datos clave. Te dice si ese número tiene mensajes previos, cuáles fueron, y sobre todo en qué modo está la conversación. Los dos modos son ai y human. Por defecto, toda conversación nueva arranca en modo ai.

Con el estado en mano, ruteás por modo:

• modo ai: el mensaje va al nodo de Claude Sonnet, que arma la respuesta con el system prompt y el historial.
• modo human: la IA queda fuera del camino. El mensaje se rutea a Twilio Flex para que lo tome una persona.

El switch de modo es lo que hace que todo funcione. Sin eso, la IA sigue respondiendo incluso después de escalar, y le terminás mandando al cliente dos respuestas seguidas: una del bot y otra de la persona. Es una mala experiencia, y además una señal de que tu sistema no tiene estado interno.

Detección de escalamiento

El nodo de IA tiene una instrucción puntual al final del system prompt: si la conversación necesita escalamiento, que agregue la etiqueta [ESCALAR] a la respuesta.

Es determinístico a propósito. No le estoy pidiendo al modelo que llame una función ni que decida el ruteo razonando. Le pido que agregue un string, y 

después chequeo ese string más abajo con una evaluación booleana simple.

IF response.includes(""[ESCALAR]"") → shouldEscalate = true

Si shouldEscalate es false, el flow saca la etiqueta, si es que apareció, arma el mensaje saliente de WhatsApp y lo manda. La conversación sigue en modo ai.

Si shouldEscalate es true, el flow hace lo siguiente:

1. Extrae los últimos 10 mensajes como contexto (por parámetro definís si querés los últimos 10, 15, 20 o la conversación completa)
2. Le manda al cliente un mensaje de espera ("Tu conversación se está transfiriendo a nuestro equipo")
3. Arranca el pipeline de Twilio Flex

El pipeline de Twilio Flex

Twilio Flex es una plataforma de contact center que maneja conversaciones multicanal: voz, SMS, WhatsApp, Instagram, Facebook. En esta arquitectura es la superficie donde las personas reciben y responden las conversaciones escaladas.

El pipeline de Flex hace tres cosas en secuencia.

Primero, busca conversaciones activas entre ese número y cualquier agente. Si hay una, la cierra. Es una restricción de Twilio Flex: las conversaciones tienen que estar en estado new para que una persona pueda aceptarlas. No podés reabrir una conversación activa y asignarla, hay que recrearla.

Segundo, crea una conversación nueva e inyecta el historial. El historial no es un volcado de mensajes crudos. Está estructurado para que quien lo recibe lo lea como un hilo coherente, no como un JSON.

Tercero, suma participantes: el cliente como originador y el agente como receptor. Arma una task con atributos de ruteo (workspace SID, workflow SID, canal en WhatsApp, iniciada por el cliente) y crea lo que Twilio llama una Interaction. Eso es lo que aparece en la consola de Flex como task entrante que un agente puede aceptar.

Cuando el agente acepta la task en la UI de Flex, ve todo el historial. Responde directo desde la consola. Esas respuestas vuelven al cliente por WhatsApp. La IA ya no participa, porque el modo pasó a human en el momento del escalamiento.

Así se vio la conversación en una sesión de prueba real:

• El cliente pregunta dónde queda la clínica → la IA responde con dirección y servicios
• El cliente pregunta por especialidades y horarios → la IA responde con la agenda completa
• El cliente dice que quiere hablar con una persona → la IA manda el mensaje de transferencia, el modo cambia y la task aparece en Flex
• El agente acepta: "Hola, buenas tardes, soy Gonzalo, ¿en qué te puedo ayudar?"
• El cliente pide un turno de dermatología para el martes
• El agente responde y cierra la conversación

De ahí en adelante, la IA no toca el hilo. El cliente recibe la respuesta de una persona con todo el contexto de lo que se dijo antes.

Dos cosas que cambiaría

Este flow se armó como prueba de concepto para el caso de un cliente puntual. Querían que la conversación viviera entera en N8N y no necesitaban guardar historial a largo plazo, porque los clientes confirmados se manejaban en un flow aparte.

Primero: dónde se guarda el estado. Hoy uso $getWorkflowStaticData(), o sea que N8N mismo es la fuente de verdad del historial. Funciona hasta que reiniciás la instancia, y ahí se pierde todo. Ese nodo habría que cambiarlo por una base de datos real: Redis, una tabla de Postgres, o hasta un Google Sheets si el volumen es bajo. Cualquier cosa externa al runtime de N8N.

Segundo: cómo se resetea el modo. Hoy la única forma de volver una conversación de modo human a modo ai es mandar el mensaje reset, que dispara una rama de debug. Existe solo por comodidad de desarrollo. Para este cliente fue intencional: una vez escalada, la conversación queda humana para siempre. Pero en producción, con varios casos de uso, querés un mecanismo en serio: un timeout, un comando del agente, o un patrón de cerrar y reabrir que resetee el modo de forma limpia.

Sobre el patrón en sí

Lo que describí se llama human-in-the-loop. Es uno de los patrones fundamentales del diseño de sistemas agénticos, y también una de esas cosas que parecen simples hasta que las implementás.

Lo difícil no es detectar cuándo escalar. Lo difícil es que, al pasar a una persona, el contexto tiene que viajar con la conversación. Si no viaja, el agente arranca de cero, el cliente tiene que repetir todo, y metiste un punto de fricción peor que no tener IA.

El enfoque de la etiqueta [ESCALAR] anda bien a esta escala. Para sistemas de más volumen, evaluaría una salida más estructurada del modelo, algo como un campo JSON escalate: true/false, en vez de parsear strings. Aguanta mejor el drift del prompt.

El sistema de modos es lo que evita que la IA dispare dos veces después del traspaso. Sin un tracking de estado explícito, dependés de que el modelo recuerde que ya escaló. No lo va a hacer. Los modelos no tienen esa persistencia. El campo de modo sí.

-Gonza