6. UX conversacional por canal: asíncrono, límites y botones

Descripción

Al terminar esta lección vas a poder adaptar la misma respuesta de tu agente a cuatro canales con criterios explícitos en vez de intuición: manejar la asincronía de la mensajería y el problema del mensaje que llega a mitad de razonamiento, decir "estoy pensando" en el idioma de cada canal, partir mensajes que superan los límites duros, aplicar el formato correcto en cada uno, y diseñar botones y respuestas rápidas con las reglas que hacen que la gente los use. Y vas a saber dónde vive cada una de esas adaptaciones, que es la pregunta que separa un sistema mantenible de un prompt lleno de parches.

Esto importa porque llegaste al punto donde tienes cuatro canales funcionando y el mismo agente detrás — y donde la mitad de las cosas que se ven mal no son errores del agente. Un mensaje que llega con asteriscos a la vista, una respuesta de nueve párrafos que en un teléfono es un muro, quince segundos de silencio sin ninguna señal de vida, un menú de siete opciones que nadie lee: nada de eso aparece como una ejecución fallida en n8n. Todo se ve verde. Y todo hace que la gente deje de usar el agente. La calidad percibida de un chatbot se decide en esta capa mucho más de lo que se decide en el prompt.

Conexión con el módulo: vienes de cuatro lecciones de canal, cada una con sus trampas de formato dispersas —el Parse Mode de Telegram, los asteriscos de WhatsApp, la imposibilidad de leer una URL por teléfono—. Esta lección junta todo eso en un método, y lo hace justo antes de la lección 7 por una razón: primero hay que saber qué se adapta para poder decidir dónde vive esa adaptación. La 7 construye la arquitectura; esta define qué tiene que hacer. El cerebro del Módulo 5 sigue, una vez más, sin tocarse — con una excepción acotada que vas a discutir al final.

La misma noticia, cuatro formas de darla

Piensa en que tienes que decirle a un cliente de TuTienda que su pedido llegó tarde y que ya se despachó el reemplazo. Es una sola noticia. Ahora imagina que la das de cuatro maneras.

Por carta, escribes párrafos completos. Explicas qué pasó, por qué, qué se hizo, y cierras con una disculpa formal. Quien la lee tiene todo el tiempo del mundo y puede releerla. Nadie se queja de que una carta sea larga.

En un pasillo, cruzándote con la persona, tienes doce segundos. Dices lo esencial: "lo tuyo se retrasó, ya salió el reemplazo, llega el jueves". Si te pusieras a explicar la logística interna, la persona se iría a mitad.

Por mensaje de texto, la persona podría leerlo ahora o dentro de tres horas. Eso cambia dos cosas: el mensaje tiene que ser autosuficiente —no puedes contar con que recuerde el contexto— y tiene que ser corto, porque va a leerlo en un teléfono, probablemente caminando.

Por teléfono, no puede releer nada. Dices una cosa, esperas, dices la siguiente. Y tienes que confirmar que te entendió, porque no hay forma de que revise.

La noticia es la misma en los cuatro casos. Los hechos son idénticos, la política de la empresa es idéntica, y la información que se transmite en el fondo es la misma. Lo que cambia es la forma de la conversación, y esa forma no la decide quien tiene la noticia: la decide el medio.

Todo lo que sigue es convertir esa intuición en cinco ejes que se pueden configurar.

Los cinco ejes

Los cinco se ven uno por uno. Y fíjate desde ahora en la última columna: cuatro de los cinco viven enteramente en la capa de adaptación. Solo el quinto toca al cerebro, y en un punto muy acotado.

Eje 1 — El ritmo: síncrono, asíncrono y el mensaje que llega tarde

Hay una diferencia entre canales que se subestima y que cambia el diseño más que cualquier otra: cuánto tiempo puede pasar entre un turno y el siguiente sin que la conversación se rompa.

Chat web      Sesión viva. La persona está mirando la pantalla AHORA.
              Si cierra la pestaña, la conversación se acabó.
              Vida media de un turno: segundos.

WhatsApp      Asíncrono de verdad. La persona pregunta y se va.
Telegram      Responde en tres horas, o mañana, o el lunes.
              La conversación no se rompe: sigue ahí.
              Vida media de un turno: horas o días.

Voz           Tiempo real duro. Un silencio de dos segundos ya es
              incómodo; uno de cinco es una llamada rota.
              Vida media de un turno: cientos de milisegundos.

Las consecuencias prácticas de esa tabla son tres, y las tres son de diseño, no de plomería.

Primera: en mensajería, cada mensaje debe ser autosuficiente. Si el agente escribe "¿cuál de los dos?" y la persona lee eso tres horas después, con veinte notificaciones de por medio, no tiene idea de a qué se refiere. La versión que funciona es "¿cuál de los dos pedidos quieres consultar, el #4521 o el #4498?". Cuesta ocho palabras más y evita un turno entero de aclaración. Es una regla que en chat web no hace falta y en WhatsApp es indispensable.

Segunda: el agente no puede dar por muerta una conversación por silencio. En chat web, si pasan diez minutos sin respuesta, la persona se fue. En WhatsApp no: probablemente vuelva. Un flujo que "cierra" la conversación tras cinco minutos de inactividad funciona en un canal y es un error en el otro.

Tercera, y la más problemática: el mensaje que llega a mitad de razonamiento.

El problema de los mensajes rápidos

Este es un problema real que casi nadie anticipa y que aparece el primer día de uso.

t=0s   Cliente:  "hola"
t=0s   n8n dispara la ejecución 1. El agente empieza a razonar.
t=2s   Cliente:  "quería preguntarte por mi pedido"
t=2s   n8n dispara la ejecución 2. OTRA instancia del agente empieza.
t=4s   Cliente:  "el 4521"
t=4s   n8n dispara la ejecución 3.
t=7s   Ejecución 1 termina → envía "¡Hola! ¿En qué te ayudo?"
t=9s   Ejecución 3 termina → envía "Tu pedido 4521 va en camino…"
t=11s  Ejecución 2 termina → envía "Claro, ¿me das el número de pedido?"

El cliente recibe tres mensajes, el último de los cuales le pide un dato que ya dio, y en un orden que no corresponde. Se ve exactamente como un bot roto. Y en n8n las tres ejecuciones salieron en verde: nadie falló.

La causa es que un webhook dispara una ejecución independiente por cada mensaje, y las ejecuciones no se enteran unas de otras. La gente, mientras tanto, escribe como habla: en ráfagas cortas. En WhatsApp esto es la norma, no la excepción.

Hay tres soluciones, con costos distintos:

Solución 1 — Agrupar por tiempo de espera (la más usada). En vez de procesar cada mensaje al llegar, se acumulan y se espera un par de segundos de silencio antes de mandarlos juntos al agente. Es lo que en programación se llama debounce.

# Patrón de agrupación por silencio

WhatsApp Trigger
   │
   ├─► Redis: agregar el texto a una lista con clave = teléfono
   │
   ├─► Wait: 3 segundos
   │
   ├─► Redis: leer la lista completa y ver si cambió
   │      ¿llegaron más mensajes mientras esperaba?
   │      ├── sí  → esta ejecución termina aquí (la última se encarga)
   │      └── no  → sigue
   │
   ├─► unir los mensajes en un solo texto
   │      "hola\nquería preguntarte por mi pedido\nel 4521"
   │
   └─► AI Agent (una sola vez, con todo el contexto)

El resultado es un agente que responde una vez, con todo lo que la persona quiso decir. Es más trabajo y vale la pena: es la diferencia entre un bot que se siente atento y uno que se siente atropellado. Requiere un almacén compartido entre ejecuciones —Redis es lo natural, pero una tabla de Postgres sirve igual.

Solución 2 — Un cerrojo por conversación. Marcar la conversación como "ocupada" mientras el agente razona, y que las ejecuciones que lleguen mientras tanto encolen su texto en vez de arrancar otro agente. Es más robusto y bastante más complejo.

Solución 3 — Aceptarlo y mitigar con velocidad. Si tu agente responde en dos segundos, la ventana de colisión es pequeña. Es la opción honesta para un proyecto en aprendizaje, y con el sistema multi-agente del Módulo 5 —que tarda entre ocho y quince segundos— no alcanza.

Para el mini-proyecto de la lección 8 basta con reconocer el problema y documentarlo. Para un sistema real en WhatsApp, la solución 1 no es opcional.

Eje 2 — La espera: cómo dice cada canal "estoy pensando"

Ya viste piezas de esto en tres lecciones distintas. Aquí está junto:

Y la regla que sale de la tabla, que es sencilla y se ignora mucho: si tu agente tarda más de tres segundos, tiene que decir algo. No importa qué canal sea; lo que cambia es el mecanismo.

Un detalle sobre el mensaje de espera que sí importa: tiene que ser específico, no genérico. Compara:

❌  "Un momento…"
✅  "Déjame revisar tu pedido, dame unos segundos."

El segundo confirma que el agente entendió la pregunta, cosa que el primero no hace. Si el agente entendió mal, la persona se entera ahora y puede corregir, en vez de esperar diez segundos para descubrirlo. Es información gratis metida en un mensaje que ibas a mandar de todos modos.

Eje 3 — La longitud: límites duros y límites de paciencia

Hay dos tipos de límite y conviene no confundirlos.

Los límites duros son de la plataforma. Si te pasas, el mensaje falla:

WhatsApp   4096 caracteres en el cuerpo de un mensaje de texto
Telegram   4096 caracteres por mensaje
           64 bytes en el callback_data de un botón
Chat web   sin límite duro relevante
Voz        no aplica: no hay caracteres, hay segundos

Los límites de paciencia son de las personas, y son mucho más bajos:

Chat web   un párrafo o dos se leen sin problema
WhatsApp   más de cuatro o cinco líneas y la gente deja de leer
Telegram   igual que WhatsApp
Voz        dos o tres frases; más allá, la información no se retiene

El límite duro produce un error visible que arreglas una vez. El límite de paciencia produce un agente que la gente abandona sin decir por qué, y ese no aparece en ninguna traza.

Para el límite duro, la solución es partir el mensaje en el adaptador de salida:

# Nodo: Code — Name: split_long_message
# Parte el texto en trozos por debajo del límite del canal, cortando
# en saltos de párrafo cuando se puede y en espacios como respaldo.
// Nunca cortes a media palabra: se ve como un error de sistema.

const MAX = 4000;              // margen de seguridad bajo los 4096
const text = $json.output;
const chunks = [];
let current = '';

for (const paragraph of text.split('\n\n')) {
  // Si agregar este párrafo pasa el límite, cierra el trozo actual.
  if ((current + '\n\n' + paragraph).length > MAX && current) {
    chunks.push(current);
    current = paragraph;
  } else {
    current = current ? current + '\n\n' + paragraph : paragraph;
  }
}
if (current) chunks.push(current);

// Un item por trozo: el nodo de envío los manda en orden.
return chunks.map(chunk => ({ json: { text: chunk } }));

Para el límite de paciencia, la solución no es partir: es generar menos texto. Y eso sí toca al cerebro, porque cuánto dice el agente es una decisión de contenido. Es la excepción que se discute más abajo.

Eje 4 — El formato

Aquí está la tabla que resuelve el 90% de los mensajes que se ven amateur:

Fíjate en la trampa central de esa tabla: el mismo asterisco significa cosas distintas. Un modelo de lenguaje escribe Markdown estándar por defecto —doble asterisco para negrita— porque es lo que vio en su entrenamiento. Eso se ve bien en el chat web y mal en WhatsApp, donde el estándar es un solo asterisco.

La conversión es de una línea en el adaptador de salida:

# Nodo: Code — Name: markdown_to_whatsapp
// El agente escribe Markdown estándar; WhatsApp usa su propia marca.
// Convertimos AQUÍ, no le pedimos al agente que escriba distinto.

let text = $json.output;

text = text.replace(/\*\*(.+?)\*\*/g, '*$1*');   // **negrita** → *negrita*
text = text.replace(/^#{1,6}\s+/gm, '');          // quita títulos de Markdown
text = text.replace(/^[\-\*]\s+/gm, '• ');        // viñetas → punto medio

return [{ json: { text } }];

Tres líneas de reemplazo y el problema desaparece para siempre, en un lugar donde puedes verlo y probarlo. La alternativa —pedirle al agente en su prompt que no use doble asterisco— falla de forma intermitente, gasta atención del modelo, y hay que repetirla en cada agente que agregues.

Para voz, la limpieza es más agresiva: quitar toda marca, convertir URLs en una oferta de enviarlas por otro medio, y convertir números y fechas a su forma hablada. Buena parte de eso se hace mejor en el dato que devuelve la tool, como viste en la lección 5.

Eje 5 — Botones y respuestas rápidas

Los botones son la mejor herramienta de UX conversacional que existe, por una razón que va más allá de la comodidad: cada botón es una ambigüedad menos para el agente. Un cliente que escribe "el de los audífonos, creo" obliga al modelo a interpretar. Un cliente que toca un botón entrega un dato exacto. Los botones no solo mejoran la experiencia: mejoran la precisión del sistema.

Qué ofrece cada canal:

Sobre WhatsApp conviene repetir la advertencia de la lección 3: la plataforma soporta mensajes interactivos, pero el nivel de soporte nativo para construirlos desde el nodo varía entre versiones de n8n, y en algunos casos hay que armar el cuerpo con un HTTP Request contra la API de Meta. Abre el selector de tipo de mensaje en tu nodo y confirma qué ofrece tu versión antes de diseñar un flujo que dependa de botones.

Cinco reglas de botones que valen para los cuatro canales

Regla 1 — Tres opciones, o una lista. Más de tres botones en una pantalla de teléfono se lee como un formulario y la gente deja de leer. Si de verdad hay siete opciones, no son siete botones: es una pregunta mal planteada que conviene partir en dos, o un mensaje de lista.

Regla 2 — Siempre una salida. Todo menú de botones necesita una opción del tipo "es otra cosa" o "hablar con una persona". Sin ella, quien no encaja en ninguna opción se queda atrapado — y mucha gente no escribe texto libre cuando ve botones, porque los botones se leen como las únicas opciones disponibles.

Regla 3 — El texto del botón es una respuesta, no una categoría. Compara "Facturación" con "Tengo un cobro que no reconozco". El segundo se elige sin pensar; el primero obliga a traducir mentalmente el problema propio a la jerga de la empresa.

Regla 4 — El dato oculto es corto y estable. order:4521, no un JSON. En Telegram hay un tope de 64 bytes y en otros canales hay topes parecidos. Y no metas ahí datos sensibles: viaja de vuelta desde el cliente.

Regla 5 — En voz, los botones se dicen y se numeran mentalmente, no se listan. "¿Es sobre un pedido, sobre un cobro, o sobre otra cosa?" — tres opciones, en una frase, en el orden en que se van a recordar. Nunca "presiona uno para…", que es un menú telefónico de los noventa y es exactamente lo que un agente de IA viene a reemplazar.

Ejemplo trabajado: una respuesta, cuatro canales

El triage_agent de TuTienda resolvió un caso con dos temas. Su salida cruda, tal como la escribiría sin adaptación alguna:

¡Hola, Ana! Revisé las dos cosas que me preguntaste.

**Sobre el cobro de $1,200 del 18 de julio:** no aparece asociado a
ninguna compra tuya en los últimos 60 días, así que abrimos la disputa
**#D-8842**. El equipo de facturación la revisa en un máximo de 48
horas hábiles y te avisamos por este mismo medio.

**Sobre el pedido #4521:** salió del centro de distribución el 21 de
julio y la entrega estimada es el 23 de julio. Puedes seguirlo aquí:
https://tutienda.example/track/4521

¿Te ayudo con algo más?

Ahora los cuatro canales.

Chat web. Va tal cual. El widget interpreta Markdown, las negritas se ven, el enlace es clickeable, y quien lee está mirando la pantalla. Este es el canal donde el agente puede escribir como quiere. Ninguna adaptación.

WhatsApp. Se convierte el formato y se acorta. Cuatro párrafos en un teléfono son un muro:

¡Hola, Ana! Revisé las dos cosas.

*Cobro de $1,200 del 18 de julio:* no aparece asociado a ninguna
compra tuya, así que abrimos la disputa *#D-8842*. Te avisamos por
aquí en un máximo de 48 horas hábiles.

*Pedido #4521:* va en camino, llega el 23 de julio.
Seguimiento: https://tutienda.example/track/4521

¿Algo más?

Qué cambió: doble asterisco a simple, se quitó la fecha de despacho (dato de proceso, no de valor), se quitó "centro de distribución" (jerga interna), y el cierre pasó de siete palabras a dos. El enlace se queda: en WhatsApp los enlaces funcionan y son útiles.

Telegram, con botones. Aquí se aprovecha lo que el canal permite:

Text (sin Parse Mode, texto plano):

  ¡Hola, Ana! Revisé las dos cosas.

  Cobro de $1,200 del 18 de julio: no aparece asociado a ninguna
  compra tuya. Abrimos la disputa #D-8842 y te avisamos en 48 horas
  hábiles como máximo.

  Pedido #4521: va en camino, llega el 23 de julio.

Inline Keyboard:
  Fila 1: "Ver seguimiento del pedido"  → url: https://tutienda.example/track/4521
  Fila 2: "Ver detalle de la disputa"   → callback_data: "dispute:D-8842"
  Fila 3: "Necesito otra cosa"          → callback_data: "menu:other"

Fíjate en dos decisiones. El enlace salió del texto y se convirtió en un botón —un botón de tipo URL, que Telegram soporta— lo cual limpia el mensaje y hace la acción más evidente. Y hay una salida explícita en la tercera fila, cumpliendo la regla 2.

Voz. Se rehace por completo:

Turno 1:
  "Revisé las dos cosas. El cobro de mil doscientos pesos no
   corresponde a ninguna compra tuya, así que ya abrimos una disputa
   y el equipo la revisa en máximo dos días hábiles."

  [pausa — esperar reacción]

Turno 2:
  "Y sobre tu pedido: va en camino y llega el jueves.
   ¿Quieres que te mande el enlace de seguimiento por mensaje?"

Qué cambió: un solo tema por turno con una pausa en medio, el número de disputa desapareció (nadie retiene #D-8842 de oído, y si lo necesita se le manda por escrito), "48 horas hábiles" se volvió "dos días hábiles" que es como habla la gente, la fecha se volvió "el jueves", y la URL se convirtió en una oferta de mandarla por otro canal.

Cuatro versiones. Un solo agente. Ninguna de las cuatro adaptaciones requirió cambiar el prompt del triage_agent.

Dónde vive la adaptación, y la única excepción

La regla general es la de la lección 1: el formato es del adaptador, el contenido es del cerebro. Convertir asteriscos, partir mensajes, mover un enlace a un botón, limpiar marcas para voz — todo eso son transformaciones sobre un texto ya generado, y viven en la capa de salida donde se pueden ver, probar y corregir en un solo lugar.

Pero mira otra vez el ejemplo trabajado y vas a notar algo incómodo. La versión de voz no es una transformación de la versión de chat web. No hay ninguna función que convierta cuatro párrafos con negritas en dos turnos de dos frases sin perder lo importante. La versión de WhatsApp está en la frontera: quitar la fecha de despacho es una decisión de qué información vale, no de cómo se escribe.

Eso significa que el eje de longitud sí toca al cerebro. Y hay una forma honesta de resolverlo sin llenar el prompt de reglas de canal: pasarle al agente una variable de canal, y que module solo su verbosidad.

# System Message del triage_agent — el ÚNICO fragmento consciente del canal

  Vas a recibir un campo `channel` que indica por dónde llegó el
  mensaje. Úsalo solo para decidir CUÁNTO texto escribir, nunca para
  cambiar el formato ni el contenido de tu respuesta:

  - web:      puedes escribir hasta tres párrafos.
  - whatsapp: máximo cuatro líneas. Un tema por mensaje.
  - telegram: igual que whatsapp.
  - voice:    dos o tres frases. Un solo tema por turno. Al terminar
              un tema, haz una pausa y espera antes de pasar al
              siguiente.

  No cambies el formato del texto según el canal: escribe siempre
  Markdown estándar. La conversión la hace el sistema, no tú.

Esa última frase es la que hace que el diseño aguante. El agente decide cuánto, el adaptador decide cómo se ve. Cada capa toma la decisión que le corresponde, y el prompt no crece cuando agregas un canal más — como mucho, gana una línea en esa lista.

Vale la pena reconocer el costo de esta decisión, porque no es gratis. El cerebro deja de ser completamente agnóstico del canal. Si mañana agregas un canal nuevo con otro nombre y no actualizas esa lista, el agente cae en un comportamiento indefinido. Y esas cuatro líneas ocupan contexto en cada turno.

La alternativa sería mantener versiones separadas del prompt por canal, lo cual es peor por todo lo que ya viste en la lección 1: prompts que divergen. O que el agente siempre escriba corto, para el peor canal — lo cual desperdicia el chat web, donde una explicación completa es exactamente lo que la gente quiere.

Entre las tres, una variable de canal que solo modula la longitud es el mejor equilibrio conocido. Es un buen ejemplo de que la arquitectura limpia no siempre gana: gana la que tiene el costo total más bajo, y saber justificar por qué se aceptó una impureza concreta transmite bastante más criterio que defender una regla sin excepciones.

Errores comunes

Pedirle al agente que se encargue del formato (conceptual). Qué pasa: el mensaje se ve mal en WhatsApp, y la corrección instintiva es agregar al system prompt "no uses doble asterisco". Funciona unas cuantas veces y falla de forma intermitente, porque un modelo escribe Markdown por costumbre. Después llega Telegram, otra línea; después voz, otras tres. El prompt se llena de reglas de presentación. Por qué pasa: es el arreglo de treinta segundos y el primer intento funciona. Cómo detectarlo: si el system prompt de cualquier agente menciona un carácter, una marca de formato o el nombre de un canal fuera de la lista de verbosidad, es esto. Cómo corregirlo: mueve la conversión a un nodo Code en el adaptador de salida. Tres reemplazos con expresiones regulares resuelven WhatsApp entero, se prueban en dos minutos y no fallan nunca.

Ignorar los mensajes en ráfaga (práctico). Qué pasa: el agente funciona perfecto en pruebas —donde uno escribe una frase completa y espera— y en producción manda respuestas duplicadas, desordenadas, y pide datos que el cliente ya dio. Por qué pasa: la gente escribe en ráfagas de tres o cuatro mensajes cortos, cada uno dispara una ejecución independiente, y las ejecuciones no se ven entre sí. Es la norma en WhatsApp. Cómo detectarlo: mira el registro de ejecuciones filtrando por un mismo cliente; si ves tres ejecuciones con menos de cinco segundos de diferencia, es esto. Cómo corregirlo: el patrón de agrupación por silencio, con Redis o una tabla, que espera un par de segundos antes de mandar todo junto al agente. Si todavía no lo vas a implementar, al menos documéntalo como limitación conocida — es infinitamente mejor que descubrirlo con clientes reales.

Un menú de siete botones (conceptual). Qué pasa: alguien mapea las siete categorías del departamento de soporte a siete botones, y la mayoría de la gente ignora el menú y escribe texto libre igual, lo cual anula el beneficio entero. Por qué pasa: las siete categorías existen en la organización, así que parece natural exponerlas. Cómo detectarlo: si menos de la mitad de la gente usa tus botones, el menú es demasiado largo o las etiquetas están en jerga interna. Cómo corregirlo: tres opciones máximo, escritas como diría el cliente su problema y no como lo llama la empresa, más una salida explícita. Si de verdad hacen falta siete, es una pregunta que conviene partir en dos niveles — pero antes vale la pena preguntarse si el agente puede clasificar solo, que para eso está.

Partir mensajes cortando a media palabra (práctico). Qué pasa: la respuesta supera los 4096 caracteres, un Code la parte cada 4000, y el cliente recibe un mensaje que termina en el pedido es y otro que empieza en tá en camino. Se ve peor que si el mensaje hubiera fallado. Por qué pasa: partir por número de caracteres es la implementación de una línea, y funciona hasta que un corte cae dentro de una palabra. Cómo detectarlo: manda a propósito una consulta que genere una respuesta larga y mira dónde corta. Cómo corregirlo: cortar en saltos de párrafo primero, en espacios como respaldo, y nunca a media palabra. Y antes de eso, preguntarse por qué el agente escribió 4000 caracteres: casi siempre el problema real es de verbosidad, no de partición.

Un mensaje de espera genérico (práctico). Qué pasa: el agente manda "Un momento…" y después de doce segundos responde algo que no tiene nada que ver con lo que el cliente preguntó, porque entendió mal desde el principio. Doce segundos perdidos. Por qué pasa: el mensaje de espera se escribe como texto fijo, sin usar lo que ya se sabe de la consulta. Cómo detectarlo: lee tu mensaje de espera; si sirve igual para cualquier pregunta, es genérico. Cómo corregirlo: que el mensaje repita lo que el agente entendió — "déjame revisar tu pedido", "voy a buscar ese cobro". Confirma la comprensión y da la oportunidad de corregir antes de gastar los doce segundos. Es información gratis en un mensaje que ibas a mandar igual.

Ejercicios

Ejercicio 1 — Adapta una respuesta difícil. El billing_specialist de TuTienda devuelve que la disputa se resolvió en contra del cliente: el cargo era legítimo, corresponde a una suscripción que el cliente activó hace tres meses, y no habrá reembolso. El triage_agent tiene que comunicarlo. Escribe la respuesta para WhatsApp (máximo cuatro líneas, con botones si tu versión los soporta) y para voz (dos turnos). Después escribe una línea sobre qué es lo más difícil de adaptar en una mala noticia.

Ana, ya revisamos la disputa #D-8842. El cargo de $1,200 corresponde
a tu suscripción Premium, activa desde el 15 de abril, así que no
procede el reembolso.

Entiendo que no era la respuesta que esperabas. Puedo ayudarte a
cancelar la suscripción si ya no la quieres.

[Cancelar la suscripción]  [Hablar con una persona]

Turno 1:
  "Ana, ya revisamos tu caso. El cargo de mil doscientos pesos
   corresponde a tu suscripción Premium, que está activa desde
   abril, así que no procede un reembolso."

  [pausa — dejar que reaccione]

Turno 2 (según lo que diga):
  "Entiendo. Si ya no quieres la suscripción puedo cancelarla ahora
   mismo, o te paso con alguien del equipo. ¿Qué prefieres?"

Ejercicio 2 — Diseña la agrupación. Escribe el flujo de agrupación por silencio para WhatsApp: qué nodos usarías, qué guardas y con qué clave, cuánto esperas, y cómo decide una ejecución si le toca procesar o retirarse. Después responde: ¿qué pasa si el cliente manda un mensaje mientras el agente ya está razonando, después de que la agrupación cerró?

WhatsApp Trigger
  │
  ├─► Redis: RPUSH  clave = "buffer:{{ phone }}"  valor = el texto
  ├─► Redis: obtener la longitud de la lista → guardarla como len_before
  │
  ├─► Wait: 3 segundos
  │
  ├─► Redis: obtener la longitud otra vez → len_after
  │
  ├─► IF: len_after > len_before
  │      ├── sí → NoOp. Llegaron más mensajes; la última ejecución
  │      │        se encargará de todos. Esta se retira.
  │      └── no → sigue
  │
  ├─► Redis: leer la lista completa y BORRARLA
  ├─► Code: unir los textos con saltos de línea
  │
  └─► AI Agent  →  responder

Ejercicio 3 — Audita tus cuatro canales. Toma tres respuestas reales de tu agente de TuTienda —una corta, una larga y una con una negativa— y pásalas por esta lista en cada canal que tengas montado. Anota cuántas casillas fallan.

• El formato se ve como debe (nada de asteriscos a la vista, nada de marcas leídas en voz alta).
• Ninguna respuesta supera el límite duro del canal.
• Ninguna respuesta supera el límite de paciencia (cuatro líneas en mensajería, dos frases en voz).
• Si el agente tardó más de tres segundos, hubo una señal de espera.
• La señal de espera fue específica, no genérica.
• Cada mensaje es autosuficiente: se entiende leído tres horas después.
• Si hay botones, no son más de tres y hay una salida explícita.
• En voz, no se dijo ninguna URL ni ningún identificador largo.

Resumen y siguiente paso

Ya tienes el método para adaptar una conversación a su canal, en cinco ejes. El ritmo te obliga a escribir mensajes autosuficientes en mensajería y a resolver el problema de las ráfagas, que es real y aparece el primer día. La espera tiene un mecanismo distinto en cada canal y una regla común: más de tres segundos exige decir algo, y ese algo conviene que sea específico. La longitud tiene límites duros que rompen el mensaje y límites de paciencia que rompen el producto, y solo los primeros se resuelven partiendo. El formato se convierte en el adaptador con tres reemplazos, nunca pidiéndoselo al agente. Y la interacción con botones no es solo comodidad: cada botón es una ambigüedad menos, con cinco reglas que valen para los cuatro canales.

Y tienes ubicada la única excepción legítima a la separación de capas: una variable de canal que el agente usa para modular cuánto texto escribe, nunca cómo se ve. El agente decide cuánto, el adaptador decide cómo. Sabiendo, además, qué cuesta esa impureza y por qué se acepta.

Antes de avanzar deberías poder: explicar por qué el mismo asterisco se ve bien en un canal y mal en otro, y dónde se corrige; describir el problema de las ráfagas y por qué la agrupación lo reduce sin eliminarlo; y nombrar las cinco reglas de botones sin mirar.

Lo que todavía no tienes es dónde poner todo esto. Tienes cuatro canales, cinco ejes de adaptación y un cerebro que no debe enterarse — y si los implementas canal por canal terminas con cuatro copias de la lógica, que es exactamente el error que la lección 1 marcó. La lección 7 construye la arquitectura que lo resuelve: un núcleo único en un sub-workflow, adaptadores delgados por canal, y un contrato de datos entre ambos tan explícito como el contrato entre agentes del Módulo 5.

Recursos

• Chat node — n8n Docs — los mensajes intermedios y los botones de aprobación del canal web, con sus tipos de respuesta.
• Telegram node — n8n Docs — el teclado en línea, los botones de tipo URL y la acción de chat typing.
• WhatsApp interactive messages — Meta for Developers — la estructura de los botones y las listas, útil sobre todo si tu versión del nodo no los expone y tienes que armarlos con HTTP Request.
• Formatting options — Telegram Bot API — la lista de caracteres que hay que escapar en cada parse mode, y la razón de que esta lección recomiende texto plano.
• Redis node — n8n Docs — el almacén compartido entre ejecuciones que hace posible el patrón de agrupación por silencio.
• Wait node — n8n Docs — la pausa de la agrupación; conviene entender cómo se comporta con muchas ejecuciones en paralelo antes de llevarlo a producción.
• Code node — n8n Docs — donde viven las conversiones de formato y la partición de mensajes largos, con su modo de un item por elemento devuelto.