Module 6: Real Channels: Web Chat, WhatsApp, Telegram, and Voice

1. Introduction: bringing the agent to real channels

Description

By the end of this lesson you'll be able to explain why the channel a message arrives through isn't a connection detail but a product decision, tell apart the three layers that make up a deployed agent — the channel, the adapter, and the brain — and place each of the seven lessons that follow inside that architecture. You'll also have, before spending a single dollar, the honest map of which channel is free, which one costs real money, and which one requires someone to verify your business with Meta.

This matters because the system you left built at the end of Module 5 works perfectly in exactly one place: your own n8n instance's chat panel. A triage_agent that receives the customer, delegates to order_specialist or billing_specialist, interprets a structured output contract, and composes a single response. All of that is real and all of it is tested with seven cases. And no TuTienda customer can use it, because reaching that panel would require giving them access to your n8n instance, which you obviously aren't going to do. An agent with no channel is an engine with no chassis: it starts, it revs, it makes noise, and it takes nobody anywhere.

Connection to the module: this is Module 6's first lesson and it's purely a map — you're not going to configure a single credential yet. Lesson 2 opens the first real channel, the web chat, which is the only one you can fully set up in fifteen minutes and for free. Lesson 3 goes to WhatsApp, which is where customers actually are in LATAM and also where the first costs and paperwork show up. Lesson 4 uses Telegram as the cheap lab that lets you practice with no paperwork. Lesson 5 — the angle almost nobody teaches — is voice. Lesson 6 adapts the conversation to each channel, and lesson 7 gives you the architecture that avoids duplicating the brain four times. Everything you're bringing from Module 5 stays intact: the agents, the tools, the contracts, and the brakes don't change because you connected them to a different door. That's, in fact, this module's thesis.

The store that only serves through the service entrance

Think of a business that does everything right on the inside. The merchandise is well organized, inventory is up to date, the counter staff knows how to answer, the payment system works. On the inside, it's a good business. And yet almost nobody buys there, for a silly reason: the only entrance is a service door in a side alley, with no sign, that you have to push hard to open.

Nobody would say that business's problem is the quality of its service. The problem is the door. And the fix isn't improving the counter even more — it's opening an entrance on the main street, putting up a sign, and maybe also serving people by phone for whoever can't make it there.

Now notice something that usually goes unnoticed, because it's where this module gets interesting. Opening the main-street entrance does not mean hiring another counter person who only serves whoever comes in that way. That would be absurd: two people with the same information, the same policies, and the same forms, who need to be trained twice and corrected twice every time a rule changes. The sensible thing is one single person serving, and several entrances leading to them.

But it's not true either that the entrance makes no difference at all. Whoever comes in through the main street sees the display window, can point at a product with their finger, and can wait right there for the answer. Whoever calls by phone sees nothing, can't point, and if you read them a list of twelve products they won't remember a single one. Whoever sends a written message can vanish for two hours and come back as if nothing happened. Same person serving, same policies, same information — and yet the conversation takes a different shape at each entrance.

That's exactly this module's problem, and also its answer: one brain, several doors, and a thin translation layer in between. What changes between WhatsApp and your website's chat isn't what the agent knows or what it can do. What changes is how the message arrives, how the person gets identified, how long a silence can last before the conversation is considered dead, how much text the screen tolerates, and whether there are buttons or not.

Worked example: the same response, four channels

Let's take a single output from Module 5's system and watch it arrive through four different doors. The brain is identical in all four cases: same triage_agent, same specialists, same tools, same Structured Output Parser. The only thing that changes is the door.

The customer asks about their order. order_specialist returns its usual contract:

{
  "status": "resolved",
  "summary": "Order 4521 left the distribution center on 07/21 and its estimated delivery is 07/23.",
  "data": {
    "order_status": "in_transit",
    "eta": "2026-07-23",
    "return_eligible": null,
    "return_deadline": null
  },
  "missing": []
}

And the triage_agent composes, in its own words, a response for the customer. Let's say it drafts this:

"Hi there! I already checked your order #4521. It left the distribution center on July 21st and the estimated delivery is July 23rd. You can track it in real time here: https://tutienda.example/track/4521 — anything else I can help with?"

Perfect. Now watch it arrive through each door.

Door 1 — Web chat embedded on tutienda.example. It arrives as-is. The **#4521** shows up bold because the widget interprets Markdown, the link is clickable, the customer is looking at the screen at this exact moment because they typed their question eight seconds ago, and if the agent takes two more seconds the widget shows three animated dots saying "thinking." It's the most forgiving channel there is, and that's why you're going to set it up first: almost nothing you do there breaks.

Door 2 — WhatsApp. It almost arrives. Markdown's double asterisks aren't bold in WhatsApp — WhatsApp uses a single asterisk, so the customer literally sees **#4521** with the asterisks showing, and that looks amateurish. The link does work. The three dots don't exist: if the agent takes eight seconds, the customer sees absolute silence and doesn't know whether the message went through. And there's something much bigger that isn't visible yet in this example: if the customer replies to this response twenty-six hours later, your business can no longer respond freely without using a template approved and paid for by Meta. That's not a formatting detail: it's a channel business rule that's going to change how you design the entire conversation.

Door 3 — Telegram. It arrives, but the format depends on a parameter you have to choose yourself: Telegram doesn't interpret Markdown by default, you have to tell it to with Parse Mode, and if you turn it on and the text carries a stray underscore or asterisk — perfectly possible in a product name — the whole message fails with a Telegram API error. On the other hand, Telegram does let you put buttons under the message with no paperwork at all, and it doesn't charge anything, and it doesn't ask anyone to verify a business. It's the best place in the world to practice.

Door 4 — Voice, over the phone. Here it doesn't arrive. It breaks, and it breaks in an interesting way. A text-to-speech engine would read that response roughly like this: "hi there, I already checked your order, asterisk asterisk, number four five two one…" — or, if the engine is smarter and strips the asterisks, it's still going to read a complete URL out loud, letter by letter, including the colons and the slashes, for about fifteen uncomfortable seconds. Nobody listens to a URL over the phone. On top of that, the person on the other end can't re-read anything: if you give them the dispatch date and the estimated date together, they're only going to retain one of the two. In voice, that same information gets said like this: "Your order's on the way and should arrive Thursday. Want me to text you the tracking link?" Two sentences, one important piece of data, and the URL gets sent through another channel.

Four doors, one single brain, and four outcomes ranging from perfect to unusable without the agent changing a single comma. That gap is the whole module.

A deployed agent's three layers

What you just saw sorts into three layers, and it's worth naming them now because they're going to be the vocabulary for the seven lessons that follow.

┌─────────────────────────────────────────────────────────────┐
│  LAYER 1 — CHANNEL                                           │
│  Web chat · WhatsApp · Telegram · Voice                     │
│  It belongs to someone else: Meta, Telegram, Vapi. You       │
│  adapt to their rules, not the other way around.             │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│  LAYER 2 — ADAPTER                                            │
│  Input:  who wrote? what did they say? → normalized format   │
│  Output: the agent's response → the channel's format          │
│  It's yours, it's thin, and there's one per channel.          │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│  LAYER 3 — BRAIN                                              │
│  triage_agent + specialists + tools + memory                  │
│  It's Module 5's. There's ONE SINGLE ONE, and it doesn't     │
│  know which channel the message came from (unless you tell   │
│  it on purpose).                                               │
└─────────────────────────────────────────────────────────────┘

Layer 1 you don't control. WhatsApp imposes a 24-hour window and a template catalog on you; Telegram imposes 4096 characters per message on you; Vapi imposes a response format with toolCallId on you. You can complain, but you can't negotiate. A good chunk of this module is simply learning what each channel imposes on you, because these are rules that don't get deduced — you have to know them.

Layer 3 you already have built. And here's the module's good news: you're not going to touch it. Your agents' prompts, the contracts between them, the Max Iterations you calibrated, the Structured Output Parser, the four tools over Sheets or Postgres — all of that stays the same. A well-designed brain is channel-agnostic, and if you find yourself putting WhatsApp rules inside billing_specialist's system prompt, something went sideways.

Layer 2 is the one you're going to build in this module, and it's surprisingly thin. In n8n it's usually a trigger node, a Set node that normalizes fields, the call to the core, and a node that responds through the right channel. Four nodes per channel. Lesson 7 formalizes it as a reusable architecture and gives it a data contract, the same way Module 5 gave the communication between agents a contract.

It's worth saying where the professional angle of this is. When a job posting asks for "multichannel AI agents" or "AI-powered WhatsApp chatbots," what it almost always finds in candidates is one workflow per channel, with the prompt copy-pasted, slightly different in each copy because someone fixed one and forgot the others. Presenting instead a single core with three thin adapters, and being able to explain why, is a difference visible in thirty seconds of demo.

The four channels: what they cost and what they require

Before you open an account anywhere, here's the honest overview. This module isn't going to sell you on everything being free, because it isn't.

Channel	Costs money?	Requires paperwork?	Time to first message
Web chat (Chat Trigger + widget)	No. Comes with n8n.	No.	~15 minutes
Telegram	No. The bot API is free.	Create the bot with BotFather, 2 minutes, no verification.	~10 minutes
WhatsApp Business API	Yes, per message sent outside the service window. There's a free test number with limited recipients.	Yes: Meta developer account, business portfolio, app, and business verification for real production.	Hours or days, depending on verification
Voice (Vapi, Retell, ElevenLabs)	Yes, per minute of conversation, plus the phone number if you want one. There are trial credits.	Account on the platform; for real telephony, also buying or porting a number.	~1 hour for a web demo with no phone

Three things worth being clear on from the start.

First: the lesson order isn't arbitrary. Web chat and Telegram come before WhatsApp and voice precisely because you can practice on them without spending money and without waiting for approvals. If, while you're reading this module, your Meta account's business verification is pending — a completely normal thing — you can do the whole module using Telegram as a stand-in for WhatsApp and lose nothing conceptually. Lesson 8's mini-project explicitly accounts for that path.

Second: the WhatsApp Business API isn't the WhatsApp Business app. They're two different products with unfortunately similar names, and confusing them is the number-one mistake beginners make. The app is free, installs on a phone, and has no way to connect to n8n. The API is a Meta service that runs in the cloud, connects via webhooks, and is the only one useful for an agent. Lesson 3 dedicates its entire first section to that distinction because getting it wrong costs money.

Third: in voice, almost everything is billed per minute of conversation. Speech recognition, the language model, and voice synthesis get billed separately on some platforms and bundled on others, but in every case the clock runs while someone's talking. A voice agent that rambles and stretches the call three minutes isn't just a bad experience: it's more expensive. That changes how a voice prompt gets written, and lesson 5 covers it with numbers.

What this module doesn't cover

Two boundary clarifications, so you know where to look for what isn't here.

It doesn't cover operating these channels in production at scale. Token rotation, external secrets, webhook high availability, monitoring for failed deliveries, retry policy when Meta goes down: all of that belongs to the ecosystem's production and maintenance guide. Here you get as far as having the channel working, verifiably, and understanding its limits.

It doesn't cover the agent's security against what comes in through those channels. A public channel is, by definition, a text input anyone can write to — and that's exactly prompt injection's vector. It's a big enough topic to have its own module, and it's Module 7, which comes right after this one for that reason. Here you're going to open the doors; there you're going to put in the locks. If opening a public channel with no guardrails worries you, that worry is correct and it's on the calendar: the order is open, verify, and then harden.

This module's map

Lesson	What it resolves
2	The first real channel: `Chat Trigger` in its two modes, the `Chat` node for responding, and the `@n8n/chat` widget embedded on TuTienda's website
3	WhatsApp Business API: Meta's pieces, the two credentials n8n needs, the `WhatsApp Trigger`, the 24-hour window, and what gets paid for
4	Telegram: BotFather, the `Telegram Trigger`, inline buttons, and `Callback Query` — the lab channel
5	Voice: the ASR → LLM → TTS stack, the two possible architectures, and how n8n connects to Vapi, Retell, and ElevenLabs as a tool
6	UX per channel: asynchrony, length, format, buttons, and voice's pacing — the same response written four times
7	The architecture: a single core in a sub-workflow, adapters per channel, and the data contract between them
8	Mini-project: Module 5's system serving through web chat and WhatsApp at the same time, with shared memory

The order has a logic. Lessons 2, 3, 4, and 5 are about channels: each one gives you a complete channel, with its nodes, its credentials, and its traps. Those four can be read a bit out of order if your situation calls for it — if your Meta verification isn't ready, skip 3 and come back. Lessons 6 and 7 are about architecture, and those do go in order and go after: they only make sense once you've already suffered the same response looking bad on two different channels. Lesson 8 assembles it all.

By the end of the module you're going to have the capability it declares: bringing the same agent to web chat, WhatsApp, Telegram, and voice, with a reusable architecture and UX suited to each channel.

A detail that's going to come back: the customer's identity

There's a decision that runs through all seven lessons and it's worth planting now, because it's the most underestimated one.

In Module 3 you learned that persistent memory gets grouped by a sessionId, and that there are two ways to get one: letting Chat Trigger generate an ephemeral one — the visitor badge — or defining it yourself with a stable identity from the real customer — the employee credential. There you saw it with an example where the phone number arrived in a webhook's body.

Every channel hands you a different identity, and none of them are the same:

Web chat (widget)  → a random sessionId per browser tab
WhatsApp           → the customer's phone number (stable, real)
Telegram           → a numeric chat ID for the bot with that person
Voice (telephony)  → the number they called from, or a call ID

Notice the problem this creates. The same TuTienda customer writes to you Monday over WhatsApp from 5215512345678, and Wednesday opens the web chat from their work computer. For your system, today, those are two different people, and Wednesday's agent has no idea what got discussed on Monday.

That has a solution, and it isn't complicated, but it's a design decision that needs to be made on purpose and not discovered by accident. Lesson 7 covers it in depth and lesson 8's mini-project forces you to resolve it. For now it's enough to have the question planted: does the conversation history belong to the channel, or does it belong to the customer? Both answers are defensible and lead to different architectures.

Common mistakes

Copying the whole workflow for every channel (conceptual). What happens: someone has their agent working with Chat Trigger, wants to add WhatsApp, and does the fastest thing: duplicates the workflow, swaps the trigger, swaps the response node, done. It works the same day. Three weeks later there are four copies, triage_agent's system prompt is different in each one because someone fixed a rule in two of the four, and nobody knows which one is the right one. Why it happens: duplicating is the cheapest action in the short term and n8n does it in two clicks; the cost shows up later, once the system's already in use. How to spot it: search whether your system prompt's text shows up more than once in your instance; if it does, you already have the problem even if it doesn't hurt yet. How to fix it: lesson 7's architecture — a core in a sub-workflow and thin adapters — solves exactly this, and migrating two copies into that shape takes less time than reconciling two diverging prompts even once.

Putting channel rules inside the agent's prompt (conceptual). What happens: the agent responds with Markdown WhatsApp doesn't interpret, and the instinctive fix is adding to the system prompt "don't use double asterisks, WhatsApp doesn't understand them." Then Telegram arrives, which does understand them, differently, and another line gets added. Then voice arrives, and another one. The brain's prompt fills up with presentation rules and the agent starts failing at its actual job, because part of its attention goes into remembering formatting rules. Why it happens: it's the shortest fix and it works the first time. How to spot it: if any of your agents' system prompts mentions a channel by name, that line is in the wrong layer. How to fix it: formatting is the output adapter's responsibility, not the brain's — lesson 6 shows how, and lesson 7 shows where it lives. There's one legitimate exception, and lesson 6 discusses it: passing the agent a channel variable so it can modulate its response's length, which is genuinely a content decision, not a formatting one.

Starting with WhatsApp because it's the one you need (practical). What happens: someone goes straight to the channel their client asked for, runs into Meta's business portfolio, the token that expires, the pending verification, and the test number with limited recipients, and spends three days without writing a single line of agent. Why it happens: it's perfectly rational to go first to what's needed; the problem is WhatsApp is the channel with the most moving parts outside your control and the worst place to learn the pattern. How to spot it: if you've spent more than an hour in Meta's panel without having sent a single test message, this is it. How to fix it: set up lesson 2's web chat first — fifteen minutes, zero paperwork — and validate there that your brain responds well through an external channel. With that working, WhatsApp becomes a credentials problem, which is much narrower than a credentials-and-agent problem at the same time.

Exercises

Exercise 1 — Classify your own case. Think about the agent you actually want to build, whether it's TuTienda's or your own. Write: (a) which channel 80% of real messages would arrive through; (b) what customer identity that channel hands you; (c) whether that identity is stable across conversations or gets lost. Then write which second channel you'd add and whether it shares identity with the first.

See solution

There's no single answer, but the pattern that comes up almost always in LATAM is this: 80% arrives through WhatsApp, the identity is the phone number, and it's stable — the same number today and in six months. That's, in fact, the best possible case for persistent memory, because the channel hands you a real, trustworthy customer identity for free.

The second channel is usually the web chat, and that's where the friction shows up: the widget hands you a random sessionId per tab, so it shares no identity with anything. You have three possible ways out, and all three are legitimate depending on the case:

Accept that they're separate conversations. Perfectly valid if the web chat mostly serves anonymous visitors who aren't customers yet. There's nothing to unify because you don't know who that person is.
Ask the user to identify themselves in the web chat (email or phone) and use that as the memory key from that point on. It's the most common path and the one you'll see in the mini-project.
Inject the identity from your own website, if the chat lives inside an authenticated session. If the customer already logged into tutienda.example, your page knows their customer_id and can pass it to the widget. It's the best option when it exists, and lesson 2 shows exactly how.

Why the exercise works: it forces you to look at identity before building, which is when the decision is cheap. Discovering it afterward means migrating conversation histories between keys, which is considerably more unpleasant work.

Exercise 2 — Rewrite the response for voice. Take this lesson's worked example's response (the order #4521 one, with bold text and a URL) and rewrite it so a text-to-speech engine can read it over the phone without sounding bad. Constraints: at most two sentences, no URL read out loud, and the date said the way a person would say it. Then write one line explaining what information you sacrificed and why it's fine to sacrifice it.

See solution

One possible version:

"Your order's already on its way and should arrive Thursday. Want me to text you the tracking link?"

What got sacrificed and why it's fine:

The order number. In voice it's noise: the person already knows which order they're asking about, because they just asked about it. Repeating "four five two one" back to them adds nothing and eats up three seconds of a call billed by the minute.
The dispatch date (July 21st). It's a process detail, not a value one. What the person wants to know is when it arrives, not when it left.
The exact date in calendar format. "Thursday" is how people talk when it's two days out. "July twenty-third" forces whoever's listening to do mental math. If the date were three weeks out, then saying the day of the month would make sense.
The URL. It doesn't get read: it gets offered through another channel. That "want me to text it to you?" is also a voice UX move worth noticing — it turns a piece of data impossible to convey by audio into a concrete action the agent can execute with a tool.

The interesting part is that none of those decisions can be made by order_specialist, because it doesn't know which channel its response is going to go out through. They're made by the adaptation layer. That's lesson 6's entire argument.

Why it works: the exercise makes visible, in a concrete case, that "adapting to the channel" isn't changing the format — it's changing what information gets conveyed. That's a product decision, not a plumbing one.

Exercise 3 — Place each piece in its layer. For each of these seven elements, say whether it belongs to the channel layer, the adapter layer, or the brain layer. Justify the two that seem most debatable to you.

triage_agent's Max Iterations.
The rule that WhatsApp doesn't allow responding freely after 24 hours.
The expression that extracts the customer's phone number from the incoming payload.
The lookup_order tool's Description.
Telegram's 4096-character-per-message limit.
The Set node that splits the response into two messages if it exceeds that limit.
The decision that the agent never promises an exact delivery date.

See solution

Brain. It's an agentic loop brake, calibrated in Module 5. It doesn't change per channel.
Channel. It's a rule Meta imposes. You didn't choose it and you can't change it; you can only design around it.
Input adapter. It's pure translation: taking the format the channel sends and producing the normalized field the core expects.
Brain. A tool's contract has nothing to do with which door the message came in through.
Channel. Same as 2: imposed by Telegram.
Output adapter. It's your response to the channel's constraint. Notice the symmetry with 5: the limit is the channel's, handling the limit is the adapter's.
Brain. It's one of TuTienda's business rules, written into order_specialist's role sheet in Module 5. It applies the same over the phone as in chat.

The two debatable ones are usually 6 and 7.

6 feels like it belongs to the channel because it talks about Telegram, but notice the distinction: the 4096-character limit exists whether you do anything or not; the node that splits the message exists because you put it there. Everything you build in response to a channel constraint is an adapter. That distinction sounds like vocabulary and it isn't: it's what tells you where to put the node.

7 gets debated because someone could argue that in voice it's even more worth being cautious about dates. And that's true — but the rule against promising exact dates already existed before there were channels, it comes from a TuTienda policy, and it applies across all four. If in voice you additionally wanted to round to "this week," that would indeed be an output adaptation. The practical test is this: if you turn off every channel but one, does the rule still make sense? If yes, it's the brain's.

Why it works: this exercise installs the three-layer vocabulary before you touch a single node. Almost every architecture mistake in this module is, at bottom, putting something in the wrong layer — and those are much easier to prevent than to fix.

Summary and next step

What you saw in this lesson is the framework before the first credential. The agent you built in Module 5 doesn't change by having channels: what changes is that two layers appear on top of it — the channel, which you don't control, and the adapter, which you do — and that every channel imposes its own rules of identity, timing, length, and format. One brain, several doors, and a thin translation layer in between. And a cost warning worth not forgetting: web chat and Telegram are free, WhatsApp costs per message and requires business verification, and voice gets billed per minute of conversation.

Before moving on to lesson 2 you should be able to: name the three layers and give an example of each one; explain why the agent's same response looks fine in the web chat and bad in WhatsApp without the agent having changed; and say what customer identity each of the four channels hands you.

What you still don't have is an open door. Lesson 2 opens the first and friendliest one: n8n's Chat Trigger, its two modes, the node you respond with, and the widget that pastes into a web page with two lines of HTML. In fifteen minutes, and without paying anyone, Module 5's system is going to be serving customers from tutienda.example.

Resources

Chat Trigger node — n8n Docs — the node lesson 2 opens with; worth arriving having already read its two modes.
WhatsApp Trigger node — n8n Docs — the official reference for lesson 3's channel, including the warning about one single webhook per app.
Telegram Trigger node — n8n Docs — lesson 4's lab channel, free and with no paperwork.
WhatsApp Business Platform pricing — Meta for Developers — the source of truth on message categories and the service window; swap it in mentally every time you read a price on a blog.
Execute Sub-workflow node — n8n Docs — the mechanism lesson 7 is going to use to turn your agent into a reusable core.
Memory in n8n — n8n Docs — worth re-reading how sessionId groups the history, which is the decision every channel puts back on the table.

← Previous8. Mini-project: triage → specialist system (2-3 agents)Next →2. Chat Trigger and embedded web widget