1. Introducción: llevar el agente a canales reales

Descripción

Al terminar esta lección vas a poder explicar por qué el canal por el que llega un mensaje no es un detalle de conexión sino una decisión de producto, distinguir las tres capas que componen un agente desplegado —el canal, el adaptador y el cerebro— y ubicar cada una de las siete lecciones que siguen dentro de esa arquitectura. También vas a tener, antes de gastar un peso, el mapa honesto de qué canal es gratis, cuál cuesta dinero de verdad y cuál exige que alguien verifique tu negocio ante Meta.

Esto importa porque el sistema que dejaste construido al cerrar el Módulo 5 funciona perfecto en un solo lugar: el panel de chat de tu propia instancia de n8n. Un triage_agent que recibe al cliente, delega en order_specialist o en billing_specialist, interpreta un contrato de salida estructurado y compone una sola respuesta. Todo eso es real y todo eso está probado con siete casos. Y ningún cliente de TuTienda lo puede usar, porque para llegar a ese panel habría que darle acceso a tu instancia de n8n, cosa que evidentemente no vas a hacer. Un agente sin canal es un motor sin carrocería: se enciende, gira, hace ruido, y no lleva a nadie a ningún lado.

Conexión con el módulo: esta es la primera lección del Módulo 6 y es puramente mapa — no vas a configurar ninguna credencial todavía. La lección 2 abre el primer canal de verdad, el chat web, que es el único que puedes montar completo en quince minutos y sin pagar nada. La 3 va a WhatsApp, que es donde de verdad están los clientes en LATAM y también donde aparecen los primeros costos y trámites. La 4 usa Telegram como el laboratorio barato que te deja practicar sin trámites. La 5 —el ángulo que casi nadie enseña— es voz. La 6 adapta la conversación a cada canal, y la 7 te da la arquitectura que evita duplicar el cerebro cuatro veces. Todo lo que traes del Módulo 5 se mantiene intacto: los agentes, las tools, los contratos y los frenos no cambian por conectarles una puerta distinta. Eso es, de hecho, la tesis de este módulo.

La tienda que solo atiende por la puerta de servicio

Piensa en un negocio que hace todo bien puertas adentro. La mercancía está bien acomodada, el inventario está al día, la gente del mostrador sabe responder, el sistema de cobro funciona. Puertas adentro, es un buen negocio. Y sin embargo casi nadie compra ahí, por una razón tonta: la única entrada es una puerta de servicio en un callejón lateral, sin letrero, que hay que empujar fuerte para abrir.

Nadie diría que el problema de ese negocio es la calidad de su atención. El problema es la puerta. Y la solución no es mejorar todavía más el mostrador — es abrir una entrada por la calle principal, poner un letrero, y quizás también atender por teléfono para quien no puede ir hasta allá.

Ahora fíjate en algo que suele pasar desapercibido, porque es donde este módulo se pone interesante. Abrir la entrada de la calle principal no significa contratar a otra persona de mostrador que atienda solo a los que entran por ahí. Sería absurdo: dos personas con la misma información, las mismas políticas y los mismos formularios, que hay que capacitar dos veces y corregir dos veces cada vez que cambia una regla. Lo razonable es una sola persona atendiendo, y varias entradas que llevan hacia ella.

Pero tampoco es cierto que la entrada dé exactamente igual. Quien llega por la calle principal ve la vitrina, puede señalar un producto con el dedo y esperar la respuesta ahí parado. Quien llama por teléfono no ve nada, no puede señalar, y si le lees una lista de doce productos no va a recordar ninguno. Quien manda un mensaje escrito puede desaparecer dos horas y volver como si nada. Misma persona atendiendo, mismas políticas, misma información — y sin embargo la conversación tiene otra forma en cada entrada.

Ese es exactamente el problema de este módulo, y también su respuesta: un solo cerebro, varias puertas, y una capa delgada entre medio que traduce. Lo que cambia entre WhatsApp y el chat de tu sitio web no es lo que el agente sabe ni lo que puede hacer. Cambia cómo llega el mensaje, cómo se identifica a la persona, cuánto puede durar un silencio antes de que la conversación se considere muerta, cuánto texto tolera la pantalla, y si hay botones o no los hay.

Ejemplo trabajado: la misma respuesta, cuatro canales

Vamos a tomar una única salida del sistema del Módulo 5 y a mirarla llegar por cuatro puertas distintas. El cerebro es idéntico en los cuatro casos: mismo triage_agent, mismos especialistas, mismas tools, mismo Structured Output Parser. Lo único que cambia es la puerta.

El cliente pregunta por su pedido. order_specialist devuelve su contrato de siempre:

{
  "status": "resolved",
  "summary": "El pedido 4521 salió del centro de distribución el 21/07 y su entrega estimada es el 23/07.",
  "data": {
    "order_status": "in_transit",
    "eta": "2026-07-23",
    "return_eligible": null,
    "return_deadline": null
  },
  "missing": []
}

Y el triage_agent compone, con sus palabras, una respuesta para el cliente. Digamos que redacta esto:

"¡Hola! Ya revisé tu pedido #4521. Salió del centro de distribución el 21 de julio y la entrega estimada es el 23 de julio. Puedes seguirlo en tiempo real aquí: https://tutienda.example/track/4521 — ¿te ayudo con algo más?"

Perfecta. Ahora mírala llegar por cada puerta.

Puerta 1 — Chat web embebido en tutienda.example. Llega tal cual. El **#4521** se ve en negrita porque el widget interpreta Markdown, el enlace es clickeable, el cliente está mirando la pantalla en este preciso momento porque hace ocho segundos escribió su pregunta, y si el agente tarda dos segundos más el widget muestra tres puntitos animados que dicen "está pensando". Es el canal más permisivo que existe, y por eso es el que vas a montar primero: casi nada de lo que hagas ahí se rompe.

Puerta 2 — WhatsApp. Casi llega. Los asteriscos dobles de Markdown no son negrita en WhatsApp — WhatsApp usa un solo asterisco, así que el cliente ve literalmente **#4521** con los asteriscos a la vista, y eso se ve amateur. El enlace sí funciona. Los tres puntitos no existen: si el agente tarda ocho segundos, el cliente ve silencio absoluto y no sabe si el mensaje llegó. Y hay algo mucho más grande que todavía no se ve en este ejemplo: si el cliente contesta esta respuesta veintiséis horas después, tu negocio ya no puede responderle libremente sin usar una plantilla aprobada por Meta y pagada. Eso no es un detalle de formato: es una regla de negocio del canal que va a cambiar cómo diseñas la conversación entera.

Puerta 3 — Telegram. Llega, pero el formato depende de un parámetro que tienes que elegir tú: Telegram no interpreta Markdown por defecto, hay que decírselo con Parse Mode, y si lo activas y el texto trae un guion bajo o un asterisco suelto —cosa perfectamente posible en un nombre de producto— el mensaje falla entero con un error de la API de Telegram. En cambio, Telegram sí te deja poner botones debajo del mensaje sin trámite alguno, y no cobra nada, y no le pide a nadie que verifique un negocio. Es el mejor lugar del mundo para practicar.

Puerta 4 — Voz, por teléfono. Aquí no llega. Se rompe, y se rompe de forma interesante. Un motor de texto a voz leería esa respuesta más o menos así: "hola, ya revisé tu pedido, asterisco asterisco, numeral cuatro mil quinientos veintiuno…" — o, si el motor es más listo y limpia los asteriscos, igual va a leer en voz alta una URL completa, letra por letra, incluyendo los dos puntos y las barras, durante unos quince segundos incómodos. Nadie escucha una URL por teléfono. Además, la persona al otro lado no puede volver a leer nada: si le das la fecha de despacho y la fecha estimada juntas, se queda con una de las dos. En voz, esa misma información se dice así: "Tu pedido va en camino y debería llegar el jueves. ¿Quieres que te mande el enlace de seguimiento por mensaje?" Dos frases, un solo dato importante, y la URL se manda por otro canal.

Cuatro puertas, un solo cerebro, y cuatro resultados que van de perfecto a inservible sin que el agente haya cambiado una coma. Esa distancia es todo el módulo.

Las tres capas de un agente desplegado

Lo que acabas de ver se ordena en tres capas, y vale la pena nombrarlas ahora porque van a ser el vocabulario de las siete lecciones que siguen.

┌─────────────────────────────────────────────────────────────┐
│  CAPA 1 — CANAL                                             │
│  Chat web · WhatsApp · Telegram · Voz                       │
│  Es de otro: Meta, Telegram, Vapi. Tú te adaptas a sus      │
│  reglas, no al revés.                                       │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│  CAPA 2 — ADAPTADOR                                         │
│  Entrada:  ¿quién escribió? ¿qué dijo? → formato normalizado│
│  Salida:   respuesta del agente → formato del canal          │
│  Es tuyo, es delgado, y hay uno por canal.                  │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│  CAPA 3 — CEREBRO                                           │
│  triage_agent + especialistas + tools + memoria             │
│  Es lo del Módulo 5. Hay UNO SOLO, y no sabe por qué        │
│  canal llegó el mensaje (salvo que se lo digas a propósito).│
└─────────────────────────────────────────────────────────────┘

La capa 1 no la controlas. WhatsApp te impone una ventana de 24 horas y un catálogo de plantillas; Telegram te impone 4096 caracteres por mensaje; Vapi te impone un formato de respuesta con toolCallId. Puedes quejarte, pero no puedes negociar. Buena parte de este módulo es simplemente aprender qué te impone cada canal, porque son reglas que no se deducen — hay que conocerlas.

La capa 3 ya la tienes construida. Y aquí está la buena noticia del módulo: no la vas a tocar. Los prompts de tus agentes, los contratos entre ellos, el Max Iterations que calibraste, el Structured Output Parser, las cuatro tools sobre Sheets o Postgres — todo eso sigue igual. Un cerebro bien diseñado es agnóstico del canal, y si te encuentras metiendo reglas de WhatsApp dentro del system prompt de billing_specialist, algo se torció.

La capa 2 es la que vas a construir en este módulo, y es sorprendentemente delgada. En n8n suele ser un nodo de trigger, un nodo Set que normaliza campos, la llamada al núcleo, y un nodo que responde por el canal correcto. Cuatro nodos por canal. La lección 7 la formaliza como una arquitectura reutilizable y le pone un contrato de datos, igual que el Módulo 5 le puso un contrato a la comunicación entre agentes.

Vale la pena decir dónde está el ángulo profesional de esto. Cuando una oferta de trabajo pide "agentes de IA multicanal" o "chatbots de WhatsApp con IA", lo que casi siempre encuentra en los candidatos es un workflow por canal, con el prompt copiado y pegado, ligeramente distinto en cada copia porque alguien corrigió uno y olvidó los otros. Presentar en cambio un núcleo único con tres adaptadores delgados, y poder explicar por qué, es una diferencia visible en treinta segundos de demostración.

Los cuatro canales: qué cuestan y qué exigen

Antes de que abras una cuenta en ningún lado, aquí está el panorama honesto. Este módulo no te va a vender que todo es gratis, porque no lo es.

Canal	¿Cuesta dinero?	¿Requiere trámite?	Tiempo para el primer mensaje
Chat web (Chat Trigger + widget)	No. Viene con n8n.	No.	~15 minutos
Telegram	No. La API de bots es gratuita.	Crear el bot con BotFather, 2 minutos, sin verificación.	~10 minutos
WhatsApp Business API	Sí, por mensaje enviado fuera de la ventana de servicio. Hay un número de prueba gratuito con destinatarios limitados.	Sí: cuenta de desarrollador en Meta, portafolio de negocio, app, y verificación de negocio para producción real.	Horas o días, según la verificación
Voz (Vapi, Retell, ElevenLabs)	Sí, por minuto de conversación, más el número telefónico si quieres uno. Hay créditos de prueba.	Cuenta en la plataforma; para telefonía real, además, comprar o portar un número.	~1 hora para una demo web sin teléfono

Tres cosas que conviene tener claras desde ahora.

Primera: el orden de las lecciones no es casual. Chat web y Telegram están antes que WhatsApp y voz precisamente porque puedes practicar en ellos sin gastar y sin esperar aprobaciones. Si mientras lees este módulo la verificación de negocio de tu cuenta de Meta está en trámite —cosa completamente normal—, puedes hacer todo el módulo con Telegram como sustituto de WhatsApp y no perder nada conceptual. El mini-proyecto de la lección 8 contempla explícitamente esa ruta.

Segunda: WhatsApp Business API no es la aplicación de WhatsApp Business. Son dos productos distintos con nombres desafortunadamente parecidos, y confundirlos es el error número uno de quien empieza. La aplicación es gratis, se instala en un teléfono, y no tiene forma de conectarse a n8n. La API es un servicio de Meta que corre en la nube, se conecta por webhooks, y es la única que sirve para un agente. La lección 3 dedica su primera sección entera a esa distinción porque cuesta dinero equivocarse.

Tercera: en voz, casi todo se cobra por minuto de conversación. El reconocimiento de voz, el modelo de lenguaje y la síntesis de voz se facturan por separado en algunas plataformas y agrupados en otras, pero en todos los casos el reloj corre mientras alguien habla. Un agente de voz que se enreda y alarga la llamada tres minutos no es solo una mala experiencia: es más caro. Eso cambia cómo se escribe un prompt de voz, y la lección 5 lo trata con números.

Lo que este módulo no cubre

Dos aclaraciones de frontera, para que sepas dónde buscar lo que no está aquí.

No cubre operar estos canales en producción a escala. Rotación de tokens, secretos externos, alta disponibilidad del webhook, monitoreo de entregas fallidas, política de reintentos ante caídas de Meta: todo eso pertenece a la guía de producción y mantenimiento del ecosistema. Aquí llegas hasta tener el canal funcionando de forma verificable y entender sus límites.

No cubre la seguridad del agente frente a lo que llega por esos canales. Un canal público es, por definición, una entrada de texto que escribe cualquiera — y eso es exactamente el vector de la inyección de prompts. Es un tema lo bastante grande como para tener su propio módulo, y es el Módulo 7, que viene justo después de este por esa razón. Aquí vas a abrir las puertas; ahí vas a poner las cerraduras. Si te inquieta abrir un canal público sin guardrails, esa inquietud es correcta y está bien calendarizada: el orden es abrir, verificar, y después endurecer.

El mapa de este módulo

Lección	Qué resuelve
2	El primer canal real: Chat Trigger en sus dos modos, el nodo Chat para responder, y el widget @n8n/chat embebido en la web de TuTienda
3	WhatsApp Business API: las piezas de Meta, las dos credenciales que n8n necesita, el WhatsApp Trigger, la ventana de 24 horas y qué se paga
4	Telegram: BotFather, el Telegram Trigger, los botones inline y el Callback Query — el canal-laboratorio
5	Voz: la pila ASR → LLM → TTS, las dos arquitecturas posibles, y cómo n8n se conecta a Vapi, Retell y ElevenLabs como tool
6	UX por canal: asincronía, longitud, formato, botones y el ritmo de la voz — la misma respuesta escrita cuatro veces
7	La arquitectura: núcleo único en un sub-workflow, adaptadores por canal, y el contrato de datos entre ambos
8	Mini-proyecto: el sistema del Módulo 5 atendiendo por chat web y por WhatsApp a la vez, con memoria compartida

El orden tiene una lógica. Las lecciones 2, 3, 4 y 5 son de canal: cada una te da un canal completo, con sus nodos, sus credenciales y sus trampas. Esas cuatro se pueden leer un poco en desorden si tu situación lo pide —si tu verificación de Meta no está lista, salta la 3 y vuelve—. Las lecciones 6 y 7 son de arquitectura, y esas sí van en orden y van después: solo tienen sentido cuando ya sufriste que la misma respuesta se vea mal en dos canales distintos. La 8 ensambla.

Al final del módulo vas a tener la capacidad que declara: llevar el mismo agente a chat web, WhatsApp, Telegram y voz, con una arquitectura reutilizable y una UX adecuada a cada canal.

Un detalle que va a volver: la identidad del cliente

Hay una decisión que atraviesa las siete lecciones y conviene sembrarla desde ahora, porque es la que más se subestima.

En el Módulo 3 aprendiste que la memoria persistente se agrupa por un sessionId, y que hay dos formas de obtenerlo: dejar que el Chat Trigger genere uno efímero —el gafete de visitante— o definirlo tú con una identidad estable del cliente real —la credencial de empleado—. Ahí lo viste con un ejemplo donde el teléfono llegaba en el cuerpo de un webhook.

Cada canal te entrega una identidad distinta, y ninguna es la misma:

Chat web (widget)  → un sessionId aleatorio por pestaña del navegador
WhatsApp           → el número de teléfono del cliente (estable, real)
Telegram           → un chat ID numérico del bot con esa persona
Voz (telefonía)    → el número desde el que llamó, o un ID de llamada

Fíjate en el problema que esto crea. El mismo cliente de TuTienda te escribe el lunes por WhatsApp desde el 5215512345678, y el miércoles abre el chat de la web desde su computadora del trabajo. Para tu sistema, hoy, son dos personas distintas, y el agente del miércoles no tiene ni idea de lo que se conversó el lunes.

Eso tiene solución, y no es complicada, pero es una decisión de diseño que hay que tomar a propósito y no descubrir por accidente. La lección 7 la trata a fondo y el mini-proyecto de la lección 8 te obliga a resolverla. Por ahora basta con que la pregunta te quede sembrada: ¿el historial de conversación pertenece al canal o pertenece al cliente? Las dos respuestas son defendibles y llevan a arquitecturas distintas.

Errores comunes

Copiar el workflow entero para cada canal (conceptual). Qué pasa: alguien tiene su agente funcionando con Chat Trigger, quiere agregar WhatsApp, y hace lo más rápido: duplica el workflow, cambia el trigger, cambia el nodo de respuesta, listo. Funciona el mismo día. Tres semanas después hay cuatro copias, el system prompt del triage_agent es distinto en cada una porque alguien corrigió una regla en dos de las cuatro, y nadie sabe cuál es la buena. Por qué pasa: duplicar es la acción más barata a corto plazo y n8n la hace en dos clics; el costo aparece después, cuando el sistema ya está en uso. Cómo detectarlo: busca si el texto de tu system prompt aparece más de una vez en tu instancia; si aparece, ya tienes el problema aunque todavía no duela. Cómo corregirlo: la arquitectura de la lección 7 —un núcleo en un sub-workflow y adaptadores delgados— resuelve exactamente esto, y migrar dos copias a esa forma toma menos tiempo que reconciliar dos prompts divergentes una sola vez.

Meter reglas de canal dentro del prompt del agente (conceptual). Qué pasa: el agente responde con Markdown que WhatsApp no interpreta, y la corrección instintiva es agregar al system prompt "no uses asteriscos dobles, WhatsApp no los entiende". Después llega Telegram, que sí los entiende de otra forma, y se agrega otra línea. Después llega voz, y otra más. El prompt del cerebro se llena de reglas de presentación y el agente empieza a fallar en su trabajo real, porque parte de su atención se va en recordar reglas de formato. Por qué pasa: es el arreglo más corto y funciona la primera vez. Cómo detectarlo: si el system prompt de cualquiera de tus agentes menciona el nombre de un canal, esa línea está en la capa equivocada. Cómo corregirlo: el formato es responsabilidad del adaptador de salida, no del cerebro — la lección 6 muestra cómo, y la 7 dónde vive. Hay una excepción legítima, y la lección 6 la discute: pasarle al agente una variable de canal para que module la longitud de su respuesta, que sí es una decisión de contenido y no de formato.

Empezar por WhatsApp porque es el que se necesita (práctico). Qué pasa: alguien va directo al canal que le pidió su cliente, se topa con el portafolio de negocio de Meta, el token que expira, la verificación pendiente y el número de prueba con destinatarios limitados, y pasa tres días sin escribir una sola línea de agente. Por qué pasa: es perfectamente racional ir primero a lo que se necesita; el problema es que WhatsApp es el canal con más partes móviles fuera de tu control y el peor lugar para aprender el patrón. Cómo detectarlo: si llevas más de una hora en el panel de Meta sin haber mandado un mensaje de prueba, es esto. Cómo corregirlo: monta el chat web de la lección 2 primero —quince minutos, cero trámites— y valida ahí que tu cerebro responde bien por un canal externo. Con eso funcionando, WhatsApp se vuelve un problema de credenciales, que es mucho más acotado que un problema de credenciales y de agente al mismo tiempo.

Ejercicios

Ejercicio 1 — Clasifica tu propio caso. Piensa en el agente que quieres construir de verdad, sea el de TuTienda o uno tuyo. Escribe: (a) por qué canal llegaría el 80% de los mensajes reales; (b) qué identidad de cliente te entrega ese canal; (c) si esa identidad es estable entre conversaciones o se pierde. Después escribe qué segundo canal agregarías y si comparte identidad con el primero.

Ver solución

No hay una única respuesta, pero el patrón que sale casi siempre en LATAM es este: el 80% llega por WhatsApp, la identidad es el número de teléfono, y es estable —el mismo número hoy y en seis meses—. Ese es, de hecho, el mejor caso posible para memoria persistente, porque el canal te regala gratis una identidad de cliente real y confiable.

El segundo canal suele ser el chat de la web, y ahí aparece la fricción: el widget entrega un sessionId aleatorio por pestaña, así que no comparte identidad con nada. Tienes tres salidas posibles, y las tres son legítimas según el caso:

1. Aceptar que son conversaciones separadas. Perfectamente válido si el chat de la web atiende sobre todo a visitantes anónimos que todavía no son clientes. No hay nada que unificar porque no sabes quién es esa persona.
2. Pedirle al usuario que se identifique en el chat web (correo o teléfono) y usar eso como clave de memoria a partir de ese momento. Es el camino más común y el que se ve en el mini-proyecto.
3. Inyectar la identidad desde tu propia web, si el chat vive dentro de una sesión autenticada. Si el cliente ya inició sesión en tutienda.example, tu página conoce su customer_id y puede pasárselo al widget. Es la mejor opción cuando existe, y la lección 2 muestra exactamente cómo.

Por qué funciona el ejercicio: te obliga a mirar la identidad antes de construir, que es cuando la decisión es barata. Descubrirla después significa migrar historiales de conversación entre claves, que es un trabajo bastante más desagradable.

Ejercicio 2 — Reescribe la respuesta para voz. Toma la respuesta del ejemplo trabajado de esta lección (la del pedido #4521, con negritas y URL) y reescríbela para que un motor de texto a voz la lea por teléfono sin que suene mal. Restricciones: máximo dos frases, ninguna URL leída en voz alta, y la fecha dicha como la diría una persona. Después escribe una línea explicando qué información sacrificaste y por qué está bien sacrificarla.

Ver solución

Una versión posible:

"Tu pedido ya va en camino y debería llegarte el jueves. ¿Quieres que te mande el enlace de seguimiento por mensaje de texto?"

Qué se sacrificó y por qué está bien:

• El número de pedido. En voz es ruido: la persona ya sabe de qué pedido está preguntando, porque acaba de preguntar por él. Repetirle "cuatro mil quinientos veintiuno" no le aporta nada y consume tres segundos de una llamada que se cobra por minuto.
• La fecha de despacho (21 de julio). Es un dato de proceso, no de valor. Lo que la persona quiere saber es cuándo llega, no cuándo salió.
• La fecha exacta en formato de calendario. "El jueves" es cómo hablan las personas cuando faltan dos días. "El veintitrés de julio" obliga a quien escucha a hacer una cuenta mental. Si la fecha estuviera a tres semanas, ahí sí conviene decir el día del mes.
• La URL. No se lee: se ofrece mandarla por otro canal. Ese "¿quieres que te la mande?" es además una jugada de UX de voz que vale la pena notar — convierte un dato imposible de transmitir por audio en una acción concreta que el agente puede ejecutar con una tool.

Lo interesante es que ninguna de esas decisiones la puede tomar el order_specialist, porque él no sabe por dónde va a salir su respuesta. Las toma la capa de adaptación. Ese es el argumento entero de la lección 6.

Por qué funciona: el ejercicio hace visible, en un caso concreto, que "adaptar al canal" no es cambiar el formato — es cambiar qué información se transmite. Eso es una decisión de producto, no de plomería.

Ejercicio 3 — Ubica cada pieza en su capa. Para cada uno de estos siete elementos, di si pertenece a la capa de canal, a la de adaptador o a la de cerebro. Justifica los dos que te parezcan más discutibles.

1. El Max Iterations del triage_agent.
2. La regla de que WhatsApp no permite responder libremente después de 24 horas.
3. La expresión que extrae el número de teléfono del cliente del payload entrante.
4. La Description de la tool lookup_order.
5. El límite de 4096 caracteres por mensaje de Telegram.
6. El nodo Set que corta la respuesta en dos mensajes si supera ese límite.
7. La decisión de que el agente nunca prometa una fecha exacta de entrega.

Ver solución

1. Cerebro. Es un freno del bucle agéntico, calibrado en el Módulo 5. No cambia por canal.
2. Canal. Es una regla que impone Meta. No la elegiste y no la puedes cambiar; solo puedes diseñar alrededor de ella.
3. Adaptador de entrada. Es traducción pura: tomar el formato que manda el canal y producir el campo normalizado que el núcleo espera.
4. Cerebro. El contrato de una tool no tiene nada que ver con por dónde entró el mensaje.
5. Canal. Igual que el 2: impuesto por Telegram.
6. Adaptador de salida. Es la respuesta tuya a la restricción del canal. Nota la simetría con el 5: el límite es del canal, el manejo del límite es del adaptador.
7. Cerebro. Es una regla de negocio de TuTienda, escrita en la ficha de rol de order_specialist en el Módulo 5. Vale igual por teléfono que por chat.

Los dos discutibles suelen ser el 6 y el 7.

El 6 se siente de canal porque habla de Telegram, pero fíjate en la distinción: el límite de 4096 caracteres existe aunque tú no hagas nada; el nodo que parte el mensaje existe porque tú lo pusiste. Todo lo que tú construyes en respuesta a una restricción del canal es adaptador. Esta distinción parece de vocabulario y no lo es: es lo que te dice dónde poner el nodo.

El 7 se discute porque alguien podría argumentar que en voz conviene ser todavía más cauto con las fechas. Y es cierto — pero la regla de no prometer fechas exactas ya existía antes de que hubiera canales, viene de una política de TuTienda, y aplica en los cuatro. Si en voz quisieras además redondear a "esta semana", eso sí sería una adaptación de salida. La prueba práctica es esta: si apagas todos los canales menos uno, ¿la regla sigue teniendo sentido? Si sí, es del cerebro.

Por qué funciona: este ejercicio instala el vocabulario de las tres capas antes de tocar un solo nodo. Casi todos los errores de arquitectura de este módulo son, en el fondo, poner algo en la capa equivocada — y son mucho más fáciles de evitar que de corregir.

Resumen y siguiente paso

Lo que viste en esta lección es el marco antes de la primera credencial. El agente que construiste en el Módulo 5 no cambia por tener canales: lo que cambia es que aparecen dos capas encima de él —el canal, que no controlas, y el adaptador, que sí— y que cada canal impone sus propias reglas de identidad, tiempo, longitud y formato. Un solo cerebro, varias puertas, y una capa delgada de traducción entre medio. Y una advertencia de costo que no conviene olvidar: chat web y Telegram son gratis, WhatsApp cuesta por mensaje y exige verificación de negocio, y voz se cobra por minuto de conversación.

Antes de avanzar a la lección 2 deberías poder: nombrar las tres capas y dar un ejemplo de cada una; explicar por qué la misma respuesta del agente se ve bien en el chat web y mal en WhatsApp sin que el agente haya cambiado; y decir qué identidad de cliente te entrega cada uno de los cuatro canales.

Lo que todavía no tienes es una puerta abierta. La lección 2 abre la primera y la más amable: el Chat Trigger de n8n, sus dos modos, el nodo con el que se responde, y el widget que se pega en una página web con dos etiquetas de HTML. En quince minutos, y sin pagarle a nadie, el sistema del Módulo 5 va a estar atendiendo desde tutienda.example.

Recursos

• Chat Trigger node — n8n Docs — el nodo con el que abre la lección 2; conviene llegar con sus dos modos ya leídos.
• WhatsApp Trigger node — n8n Docs — la referencia oficial del canal de la lección 3, incluida la advertencia de un solo webhook por app.
• Telegram Trigger node — n8n Docs — el canal-laboratorio de la lección 4, gratis y sin trámites.
• WhatsApp Business Platform pricing — Meta for Developers — la fuente de verdad sobre categorías de mensaje y la ventana de servicio; cámbialo en tu cabeza cada vez que leas un precio en un blog.
• Execute Sub-workflow node — n8n Docs — el mecanismo con el que la lección 7 va a convertir tu agente en un núcleo reutilizable.
• Memory in n8n — n8n Docs — para releer cómo el sessionId agrupa el historial, que es la decisión que cada canal vuelve a poner sobre la mesa.