5. Agentes de voz: Vapi, Retell y ElevenLabs

Descripción

Al terminar esta lección vas a poder explicar qué hay realmente dentro de un agente de voz —la pila de reconocimiento, modelo y síntesis, y el presupuesto de latencia que la gobierna—, elegir con criterio entre las dos arquitecturas posibles para conectarlo con n8n, y registrar tus workflows como herramientas de un agente de voz en las tres plataformas que dominan el mercado: Vapi, Retell y ElevenLabs. También vas a saber escribir un prompt para voz, que no se parece a un prompt para chat, y vas a tener el mapa honesto de lo que cuesta un minuto de conversación hablada.

Esto importa por una razón de mercado bastante concreta. Cuando se revisan las ofertas de empleo que piden construir agentes con IA, la voz aparece en cerca de un 28% de ellas — más que RAG, que es el tema que todo el mundo enseña. Y casi ningún material en español lo cubre: se menciona en una diapositiva, se dice "también se puede hacer voz" y se pasa a otra cosa. Esa combinación —demanda alta, oferta formativa casi nula— es exactamente donde vale la pena invertir un rato. Además, es el canal que más obliga a repensar todo lo que llevas: sin pantalla, sin botones, sin posibilidad de releer y con un reloj corriendo, casi ninguna de tus decisiones de diseño anteriores sobrevive intacta.

Conexión con el módulo: vienes de tres canales de texto que se parecen mucho entre sí — un trigger que recibe, un cerebro que razona, un nodo que responde. Voz rompe ese molde, y por eso está al final del bloque de canales. Aquí, en la arquitectura que vas a usar, n8n deja de ser el cerebro y pasa a ser la mano: la plataforma de voz conduce la conversación y tus workflows son las herramientas que consulta. Es un giro conceptual, no un detalle de conexión, y entenderlo bien es lo que separa una demo de voz que funciona de una que se cae en la segunda frase. Todo lo que aprendiste en el Módulo 4 sobre contratos de tools se vuelve, aquí, la pieza central.

El mesero que recita el menú

Piensa en la diferencia entre leer una carta y que un mesero te recite el menú del día.

Con la carta en la mano puedes recorrerla en el orden que quieras, volver atrás, comparar dos platos, dejarla un momento para atender una llamada y retomar exactamente donde ibas. Toda la información está disponible a la vez y tú controlas el ritmo.

Cuando el mesero recita, nada de eso existe. La información llega en un orden que tú no elegiste, a una velocidad que tú no controlas, y desaparece en cuanto pasa. Si recita doce platos, recuerdas dos: el primero y el último. Si dice "el precio es de doscientos ochenta y siete pesos con cincuenta", tienes que sostener ese número en la cabeza mientras él sigue hablando. Y si te distraes tres segundos, no hay forma de rebobinar: solo pedirle que repita, cosa que la gente evita hacer porque da pena.

Por eso los buenos meseros no recitan doce platos. Dicen tres, agrupados, y preguntan. "Hoy tenemos tres pescados, dos carnes y una pasta. ¿Por dónde te oriento?" Reducen para que quepa en la memoria de trabajo de quien escucha, y devuelven el control con una pregunta.

Todo el diseño de un agente de voz sale de ahí. No es un chatbot al que se le puso un altavoz: es una conversación con reglas distintas, donde la información tiene que caber en la cabeza de alguien que no puede volver atrás. Cuando en la lección 1 la respuesta del pedido #4521 se rompió al pasarla a voz, no se rompió por el formato — se rompió porque tenía demasiada información para un canal donde la información desaparece.

Qué hay dentro de un agente de voz

Antes de conectar nada, veamos la máquina. Un agente de voz por teléfono es una cadena de tres piezas más un director de orquesta.

        La persona habla
              │
              ▼
    ┌─────────────────────┐
    │  ASR                │  Automatic Speech Recognition.
    │  voz → texto        │  Convierte el audio en palabras.
    └──────────┬──────────┘
               │  "hola quiero saber de mi pedido cuatro cinco dos uno"
               ▼
    ┌─────────────────────┐
    │  LLM                │  El modelo de lenguaje. Decide qué responder
    │  texto → texto      │  y cuándo llamar a una herramienta.
    └──────────┬──────────┘  ◄── AQUÍ es donde n8n entra como TOOL
               │  "Déjame revisarlo. Tu pedido va en camino…"
               ▼
    ┌─────────────────────┐
    │  TTS                │  Text To Speech. Convierte el texto en
    │  texto → voz        │  audio con una voz sintética.
    └──────────┬──────────┘
               │
               ▼
        La persona escucha

    Y por encima de los tres, el DIRECTOR (turn-taking):
      · VAD — detecta cuándo hay voz y cuándo hay silencio
      · endpointing — decide cuándo la persona TERMINÓ de hablar
      · barge-in — permite que la persona interrumpa al agente

Las tres piezas de la cadena las conoces conceptualmente. El director es lo que hace difícil la voz, y es lo que las plataformas venden.

Endpointing es el problema más subestimado. Cuando alguien dice "mi pedido es el… cuatro cinco dos uno", hay una pausa en medio. ¿Terminó de hablar o está pensando? Si el sistema decide demasiado rápido que terminó, interrumpe a la persona a mitad de frase, cosa que resulta muy desagradable. Si espera demasiado, la conversación se siente lenta y muerta. Ese ajuste —típicamente unos cientos de milisegundos de silencio— es una de las cosas que más diferencia a un agente de voz bueno de uno malo, y no tiene nada que ver con la calidad del modelo.

Barge-in es poder interrumpir al agente. Si el agente arranca a recitar y la persona dice "no, espera", un agente sin barge-in sigue hablando encima. Con barge-in, se calla y escucha. Es la diferencia entre hablar con algo y que algo te hable.

El presupuesto de latencia

Aquí está el número que gobierna todo el diseño de voz. En una conversación humana normal, el silencio entre que uno termina de hablar y el otro empieza es de unos 200 milisegundos. Un silencio de más de un segundo se percibe como duda; más de dos, como que la llamada se cortó.

Ahora suma la cadena:

Presupuesto aproximado de una respuesta de voz

  endpointing (esperar a confirmar que terminó)   ~200-500 ms
  ASR (transcribir lo dicho)                      ~100-300 ms
  LLM (razonar y generar la respuesta)            ~300-1500 ms   ◄── el grande
  TTS (empezar a producir audio)                  ~100-300 ms
  red (ida y vuelta)                              ~50-150 ms
  ─────────────────────────────────────────────────────────
  total percibido antes de oír la primera sílaba  ~750-2750 ms

Fíjate en dónde está el margen y dónde no. El ASR y el TTS son bastante fijos. El endpointing se ajusta pero tiene un piso. El único componente donde tus decisiones mueven cientos de milisegundos es el LLM y, sobre todo, las herramientas que llama.

Y ahí está la consecuencia que hace que esta lección tenga sentido dentro de esta guía. Si tu workflow de n8n es una tool de ese agente de voz y tarda cuatro segundos en responder, la persona al teléfono escucha cuatro segundos de silencio en medio de una frase. No hay indicador de "escribiendo", no hay tres puntitos, no hay nada. Cuatro segundos de nada.

Eso tiene tres soluciones y las tres se usan:

1. Que la tool sea rápida. Un workflow que consulta una fila de una base de datos y devuelve tres campos puede responder en menos de un segundo. Un workflow que llama a un agente de IA que a su vez delega en dos especialistas, no. Esta es la razón principal por la que el sistema multi-agente del Módulo 5 no se conecta directamente como tool de un agente de voz.
2. Que el agente hable mientras espera. Las tres plataformas tienen una opción para que el agente diga algo —"déjame revisarlo un segundo"— al empezar la llamada a la herramienta. En Retell se llama literalmente Speak During Execution. Es la versión de voz del "escribiendo…" de Telegram.
3. Que la tool sea asíncrona. El agente dispara la acción, sigue conversando, y el resultado se procesa después. Sirve para acciones que no condicionan la siguiente frase: crear un ticket, mandar un correo, registrar algo.

Las dos arquitecturas

Hay dos formas de juntar n8n con una plataforma de voz, y elegir la equivocada es el error estructural de esta lección.

Arquitectura A — la plataforma es el cerebro, n8n es la mano

   Teléfono
      │
      ▼
  ┌────────────────────────────────────────────┐
  │  Vapi / Retell / ElevenLabs                │
  │    ASR + LLM + TTS + turn-taking           │
  │    system prompt del agente                │
  │    ▼                                       │
  │    tools registradas ───────────┐          │
  └─────────────────────────────────┼──────────┘
                                    │  HTTP
                                    ▼
                          ┌──────────────────────┐
                          │  n8n                 │
                          │  Webhook → lógica →  │
                          │  Respond to Webhook  │
                          │                      │
                          │  lookup_order        │
                          │  lookup_charge       │
                          │  create_ticket       │
                          └──────────────────────┘

El agente de voz vive en la plataforma. Su prompt está allá, su modelo está allá, y el ciclo de conversación lo maneja allá. n8n aparece únicamente cuando el agente necesita consultar o hacer algo: cada workflow es una tool, expuesta como un webhook.

Esta es la arquitectura que se usa en la práctica, y esta es la que enseña esta lección. La razón es el presupuesto de latencia que acabas de ver: el turn-taking de una conversación hablada exige una coordinación entre ASR, LLM y TTS que se hace en milisegundos y con audio en streaming. n8n no está construido para eso y no debería estarlo — es un orquestador de workflows, no un motor de tiempo real.

Arquitectura B — n8n es el cerebro, la plataforma solo transporta

   Teléfono ─► plataforma (ASR + TTS) ─► webhook n8n ─► AI Agent ─► responde texto
                                                                 ─► plataforma lo lee

Aquí la plataforma solo convierte voz en texto y texto en voz, y todo el razonamiento vive en tu AI Agent de n8n. Es tentador: mantiene un solo cerebro para todos los canales, que es justo lo que la lección 7 va a predicar.

Y en voz, casi siempre es la decisión equivocada. Cada turno de conversación se convierte en un viaje de ida y vuelta completo a tu instancia de n8n, con el arranque del workflow, la llamada al modelo desde n8n, y la vuelta. Se suman fácilmente uno o dos segundos por turno, encima de todo lo demás. El resultado es un agente que responde bien y se siente inaguantable.

Hay un caso donde B sí tiene sentido: conversaciones de voz asíncronas, donde no hay un turno en tiempo real. Un mensaje de voz de WhatsApp que se transcribe, se procesa con el agente, y se responde con texto o con un audio generado — ahí no hay nadie esperando en la línea, y los tres segundos no importan. Ese caso es una extensión natural de la lección 3, no un agente de voz telefónico.

La regla práctica: si hay una persona esperando en la línea, arquitectura A. Si el audio es un mensaje que se procesa cuando llega, arquitectura B.

Vapi: registrar un workflow de n8n como tool

Veamos la mecánica concreta con Vapi, que es la plataforma con el modelo de integración más limpio para este caso.

En Vapi defines un agente (un assistant) con su prompt, su voz y su modelo. Y le registras tools. Para llamar a un endpoint tuyo, el tipo de tool es Function, y se le configura:

• Name — el identificador de la herramienta, en inglés y sin espacios: lookup_order.
• Description — para qué sirve. Esto es lo que el modelo lee para decidir si la llama. Es exactamente el mismo criterio del Módulo 4: una descripción vaga produce llamadas equivocadas.
• Server URL — la URL del webhook de producción de tu workflow de n8n.
• Parameters — el esquema JSON de los argumentos que el modelo debe extraer de la conversación.
• Async Mode y Timeout — si el agente espera el resultado, y cuánto.

Cuando el agente decide usar la herramienta, Vapi hace un POST a tu URL con un cuerpo de esta forma:

{
  "message": {
    "type": "tool-calls",
    "toolCallList": [
      {
        "id": "toolu_01DTPAzUm5Gk3zxrpJ969oMF",
        "name": "lookup_order",
        "arguments": { "order_id": "4521" }
      }
    ]
  }
}

Y espera de vuelta exactamente esta forma:

{
  "results": [
    {
      "toolCallId": "toolu_01DTPAzUm5Gk3zxrpJ969oMF",
      "result": "El pedido 4521 está en tránsito, entrega estimada el 23 de julio."
    }
  ]
}

Dos detalles que hacen fallar la mitad de las primeras integraciones:

El toolCallId de la respuesta tiene que ser el mismo id de la petición. Es el mecanismo por el que Vapi empareja tu respuesta con la llamada correcta, porque puede haber varias en vuelo. Si lo omites o lo inventas, el agente no recibe nada y se queda callado.

El result puede ser texto o un objeto, y para voz casi siempre conviene texto. Si le devuelves {"status":"in_transit","eta":"2026-07-23"}, el modelo va a tener que traducir eso a una frase hablada, y a veces lo hace mal — leyendo la fecha en formato de calendario, por ejemplo. Si le devuelves una frase ya redactada para ser dicha, el resultado es mucho más consistente. En voz, el trabajo de redacción conviene hacerlo en la tool, no dejárselo al modelo.

Ejemplo trabajado: lookup_order de TuTienda, hablado

Vamos a construir la tool completa. En n8n, un workflow de tres nodos:

Webhook (POST)  →  Postgres / Sheets  →  Respond to Webhook

Paso 1 — El webhook.

# Nodo: Webhook — Name: voice_lookup_order
HTTP Method:   POST
Path:          voice/lookup-order
Respond:       Using 'Respond to Webhook' node
Authentication: Header Auth  ← una clave compartida; ver la nota de abajo

Sobre la autenticación: este endpoint va a estar abierto a internet. Vapi permite configurar cabeceras personalizadas en la tool, así que lo mínimo razonable es una cabecera con un secreto que n8n verifique. No es criptografía seria, pero evita que cualquiera que descubra la URL consulte tus pedidos. La versión rigurosa —firmas y validación— es material del Módulo 7.

Paso 2 — Extraer el argumento. El order_id viene enterrado en la estructura de Vapi:

# Nodo: Set — Name: extract_args
# La ruta hasta los argumentos depende de la versión de la API de Vapi.
# Confirma con una ejecución real antes de darla por buena.

tool_call_id = {{ $json.body.message.toolCallList[0].id }}
order_id     = {{ $json.body.message.toolCallList[0].arguments.order_id }}

Paso 3 — Consultar. El mismo nodo de Sheets o de Postgres que usaste como tool en el Módulo 5. Sin cambios.

Paso 4 — Responder en el formato de Vapi, con el texto ya redactado para voz:

# Nodo: Respond to Webhook — Name: respond_to_vapi
# Respond With: JSON

{
  "results": [
    {
      "toolCallId": "{{ $('extract_args').item.json.tool_call_id }}",
      "result": "{{ $json.order_status === 'in_transit'
                    ? 'El pedido va en camino y llega aproximadamente el ' + $json.eta_spoken
                    : 'El pedido está ' + $json.status_spoken }}"
    }
  ]
}

Fíjate en eta_spoken y status_spoken. La idea es preparar en la consulta una versión de cada dato lista para ser dicha en voz alta: no 2026-07-23 sino el jueves 23 de julio; no in_transit sino en camino. Esa preparación es trabajo del adaptador, y hacerla aquí ahorra que el modelo improvise y a veces se equivoque.

Paso 5 — Registrar la tool en Vapi:

# Vapi > Assistant > Tools > Add Tool > Function

Name:        lookup_order
Description: Consulta el estado y la fecha estimada de entrega de un
             pedido de TuTienda a partir de su número. Úsala siempre
             que el cliente pregunte por un pedido. No sirve para
             cobros ni para devoluciones.
Server URL:  https://TU-INSTANCIA-N8N/webhook/voice/lookup-order
Parameters:
  order_id (string, requerido) — El número de pedido que dijo el
    cliente, solo dígitos. Si el cliente no lo dio, pídeselo antes
    de llamar a esta herramienta; nunca lo inventes.
Async:   No  (el agente necesita el resultado para seguir hablando)
Timeout: 10 segundos

Qué esperar. Llamas al agente, dices "quiero saber de mi pedido cuatro cinco dos uno", y el agente responde algo como "Déjame revisarlo… Tu pedido va en camino y llega aproximadamente el jueves veintitrés de julio." En n8n vas a ver una ejecución del workflow con el payload de Vapi entero. Si el agente se queda callado, los dos sospechosos son el toolCallId mal copiado y un timeout demasiado corto.

Nota una cosa importante de la descripción de la tool: es idéntica en espíritu a la del Módulo 4 —qué hace, cuándo usarla, cuándo no— pero incluye una instrucción de voz que en chat no hacía falta: "si el cliente no lo dio, pídeselo antes de llamar". En chat, un agente que llama con un dato faltante produce un error recuperable. En voz, produce un silencio y después una frase confusa, en medio de una llamada. Vale la pena ser más explícito.

Retell: la misma idea con otros nombres

Retell llama custom function a lo mismo. Su configuración incluye estos campos:

Cuando Retell llama a tu URL, el cuerpo trae tres cosas: name (el nombre de la función), args (los argumentos) y call (el objeto de la llamada, que incluye la transcripción en curso). Manda además una cabecera X-Retell-Signature que sirve para verificar que la petición viene de verdad de Retell. Hay una opción de "solo argumentos" que aplana el cuerpo y deja los argumentos en el nivel superior, cosa que simplifica bastante las expresiones.

La respuesta que espera es más simple que la de Vapi: cualquier código entre 200 y 299, con el cuerpo como texto, objeto JSON o binario, con un tope de unos 15.000 caracteres. No hay que emparejar identificadores.

Dos campos de esa tabla merecen comentario porque no tienen equivalente obvio en chat.

Speak During Execution es el "escribiendo…" de la voz. Con él activo, el agente dice algo mientras espera —"un momento, lo consulto"— y el silencio deja de existir. La recomendación general es activarlo casi siempre, salvo en funciones instantáneas o en tareas donde no se espera que el agente siga hablando.

Response Variables es más interesante de lo que parece. Permite extraer un valor de la respuesta de tu workflow y guardarlo como variable de la llamada, disponible el resto de la conversación. Si tu tool devuelve el nombre del cliente, el agente puede usarlo veinte turnos después sin volver a consultar. Es memoria de sesión provista por la plataforma, y ahorra llamadas.

Retell publica además un nodo de comunidad para n8n (@retellai/n8n-nodes-retellai), que se instala desde Settings → Community Nodes y sirve para el camino contrario: disparar llamadas salientes desde un workflow. Es útil cuando tu flujo de negocio es "cuando pase X, que el agente llame a este cliente". Ten presente que un nodo de comunidad no es un nodo oficial: se instala aparte y su mantenimiento depende de quien lo publica.

ElevenLabs: webhook tools y variables dinámicas

ElevenLabs, conocido sobre todo por la calidad de sus voces sintéticas, tiene también una plataforma de agentes conversacionales. Su mecanismo para llamar a un endpoint externo son las webhook tools (o server tools), y su configuración se parece bastante a definir una petición HTTP completa:

• Name y Description — igual que en las otras dos.
• Method y URL — el verbo y el endpoint.
• Path parameters — variables dentro de la URL, entre llaves: /orders/{order_id}.
• Query parameters — los que van después del signo de interrogación.
• Body parameters — el cuerpo, como JSON o como formulario codificado.
• Autenticación y cabeceras — soporta OAuth2, tokens Bearer, autenticación básica y cabeceras personalizadas.

Y una distinción propia que vale la pena entender, porque es elegante: cada parámetro tiene un value type, con dos opciones.

• LLM Prompt — el modelo extrae el valor de la conversación. Es lo que ya conoces: el cliente dijo un número de pedido, el modelo lo pone en el parámetro.
• Dynamic Variable — el valor sale de una variable de la llamada, no de lo que el modelo entendió. Y esas variables se pueden actualizar con las respuestas de otras herramientas.

Esa segunda opción resuelve un problema real. Imagina que al empezar la llamada tu sistema ya sabe quién llama, porque identificó el número entrante. Ese customer_id no debería salir de lo que el modelo entienda por teléfono: debería estar fijado desde el primer segundo y viajar en cada llamada a herramienta. Con una variable dinámica, el customer_id es un dato del sistema, no una interpretación del modelo. En voz, donde el reconocimiento puede confundir un dígito, cada dato que puedas sacar del ámbito de la interpretación es un error menos.

Piénsalo un momento: ¿cuántos de los datos que tu agente maneja hoy realmente tienen que salir de lo que la persona dice, y cuántos podrías conocer de antemano? En un agente de atención con identificación de llamante, la respuesta suele sorprender.

La conexión con n8n es exactamente la misma de siempre: un nodo Webhook recibiendo, la lógica en medio, y un Respond to Webhook devolviendo. Del lado de ElevenLabs, verifica en la documentación vigente cuál es el límite de tiempo de espera de una webhook tool, porque no todas las plataformas lo publican con la misma claridad y es un dato que conviene conocer antes de conectar un workflow lento.

Las tres, comparadas

Lo que conviene retener de esa tabla no es cuál es mejor —las tres funcionan y la elección suele depender del precio y de la calidad de voz en tu idioma— sino que el patrón es idéntico en las tres: defines una herramienta con nombre y descripción, apuntas a un webhook de n8n, declaras los parámetros, y devuelves un resultado. Si aprendes una, las otras dos son cuestión de leer qué nombre le pusieron a cada campo.

Ninguna de las tres tiene, al momento de escribir esto, un nodo nativo de n8n para el lado del agente. El puente es el nodo Webhook, que es genérico y estable, y eso en realidad es una ventaja: tu integración no depende de que alguien mantenga un nodo específico.

El prompt de voz es otro prompt

Aquí está la parte que más se subestima. Un system prompt escrito para chat, puesto tal cual en un agente de voz, produce un agente insufrible. Estas son las diferencias que más rendimiento dan.

Longitud: dos o tres frases, máximo. En chat, una respuesta de un párrafo se lee en cinco segundos y se puede saltar. En voz, ese mismo párrafo son veinte segundos durante los cuales la persona no puede hacer nada y probablemente ya se perdió. La instrucción tiene que ser explícita y cuantitativa: "responde en dos o tres frases; si necesitas dar más información, entrégala por partes y pregunta antes de continuar".

Nada de listas. Una lista de cinco opciones en voz es una lista que nadie recuerda. Máximo tres, y de preferencia agrupadas: "puedo ayudarte con pedidos, con cobros, o con devoluciones. ¿Cuál de los tres?".

Nada de formato. Ni asteriscos, ni viñetas, ni enlaces. Esto no es opcional: el motor de síntesis los va a leer o los va a manejar de forma impredecible.

Números y fechas, como los diría una persona. 2026-07-23 es "el jueves veintitrés de julio". $1,200.00 es "mil doscientos pesos". Un número de pedido de cuatro dígitos conviene decirlo dígito por dígito y repetirlo para confirmar. Vale la pena resolver esto en el dato que devuelve la tool, y además instruirlo en el prompt como red de seguridad.

Confirmación explícita antes de cualquier acción. En chat, si el agente entendió mal, la persona lo lee y lo corrige. En voz, el reconocimiento puede confundir un dígito y nadie se entera hasta que la acción ya se ejecutó. La regla es: repetir el dato crítico y esperar confirmación. "Entonces cancelo el pedido cuatro-cinco-dos-uno, ¿es correcto?"

Un plan para cuando no se entiende. Va a pasar: ruido, acento, una palabra a medias. El prompt tiene que decir qué hacer, y sobre todo qué hacer la segunda y la tercera vez. Preguntar dos veces está bien; a la tercera, la respuesta correcta suele ser ofrecer otra vía —"te mando un mensaje de texto para que me escribas los datos"— o transferir a una persona. Un agente que pregunta cuatro veces lo mismo es peor que no tener agente.

Un system prompt de voz para TuTienda, comparado con su versión de chat:

# System prompt de voz — TuTienda (para el assistant de la plataforma)

Eres la asistente telefónica de TuTienda. Hablas por teléfono, así
que la persona no puede leer nada ni volver atrás.

Cómo hablas:
- Dos o tres frases por turno. Nunca más.
- Sin listas de más de tres elementos.
- Sin asteriscos, viñetas, enlaces ni direcciones web.
- Las fechas como las diría una persona: "el jueves veintitrés de
  julio", no "veintitrés cero siete".
- Los números de pedido, dígito por dígito.

Antes de cualquier acción:
- Repite el dato clave y pide confirmación explícita.
- Nunca ejecutes una cancelación, un cambio o un reembolso sin
  haber recibido un "sí" claro.

Si no entiendes:
- Pide que repitan, una vez.
- Si sigues sin entender, pide el dato de otra forma (por ejemplo,
  dígito por dígito).
- A la tercera, ofrece mandar un mensaje de texto o transferir con
  una persona del equipo. No insistas más.

Nunca digas direcciones web en voz alta. Si hay un enlace que
compartir, ofrece enviarlo por mensaje.

Compáralo con el prompt del triage_agent del Módulo 5. El contenido de negocio es el mismo; lo que cambió es enteramente la forma de la conversación. Ese prompt vive en la plataforma de voz, no en n8n, y es el mejor ejemplo posible de por qué la capa de canal existe.

El post-call webhook: aquí n8n vuelve a brillar

Hasta ahora n8n fue la mano del agente durante la llamada. Hay un segundo momento donde n8n es aún más útil: cuando la llamada termina.

Las tres plataformas mandan, al colgar, un webhook con el resumen de lo ocurrido: la transcripción completa, un resumen generado, la duración, el resultado, y a menudo variables estructuradas que el agente fue recogiendo durante la conversación.

Ese webhook llega a n8n como cualquier otro, y ahí sí puedes desplegar todo lo que sabes hacer:

Webhook (post-call de la plataforma de voz)
   │
   ├─► Set: extraer transcripción, resumen, duración, número
   │
   ├─► AI Agent o Basic LLM Chain: clasificar el resultado
   │      (resuelto / requiere seguimiento / cliente molesto)
   │
   ├─► IF: ¿requiere seguimiento?
   │      ├── sí  → create_ticket + notificar al equipo
   │      └── no  → solo registrar
   │
   ├─► Postgres: guardar la conversación en el historial del cliente
   │
   └─► WhatsApp → Send Template: mandarle al cliente el enlace de
         seguimiento que no se le pudo decir por teléfono

Ese último nodo cierra un círculo bonito del módulo. La URL que en voz era imposible de transmitir se manda por WhatsApp, en el mismo flujo, al mismo cliente. Los canales dejan de ser silos y se vuelven un sistema.

Y fíjate en la penúltima rama: guardar la transcripción en el mismo almacén de memoria que usan los otros canales significa que un cliente que llamó por teléfono el lunes y escribe por WhatsApp el martes es reconocido. Esa es exactamente la promesa de la lección 7, y aquí ya se ve funcionando.

Lo que cuesta, dicho claro

Voz es el canal más caro del módulo y conviene saberlo antes de armar una demo de treinta minutos.

El modelo de cobro es por minuto de conversación. Algunas plataformas agrupan todo —reconocimiento, modelo, síntesis, telefonía— en una tarifa por minuto; otras cobran cada componente por separado y hay que sumar. En cualquier caso, el reloj corre mientras alguien habla, y el orden de magnitud típico está en el rango de unos pocos centavos de dólar por minuto. Una llamada de tres minutos cuesta poco; diez mil llamadas de tres minutos, no.

El número de teléfono se paga aparte. Si quieres que la gente pueda marcar a un número, hay que comprarlo o portar uno, con su renta mensual. Eso es independiente de lo que consumas.

Lo que tú controlas es la duración. Aquí la ingeniería y la factura coinciden por una vez: un agente que va al grano, que confirma bien a la primera y que no repite preguntas, cuesta menos. Un agente que no entiende y pregunta cuatro veces alarga la llamada y encarece cada conversación. Optimizar la experiencia y optimizar el costo son, en voz, la misma tarea.

La ruta barata para aprender, que es lo que esta lección recomienda:

1. Empieza sin número de teléfono. Las tres plataformas tienen una forma de probar el agente desde el navegador, hablando por el micrófono de la computadora. Se salta toda la parte de telefonía y su costo, y para aprender a construir la tool y a escribir el prompt es exactamente igual de útil.
2. Usa los créditos de prueba que las plataformas dan al registrarse, y mira el consumo después de cada sesión de trabajo para calibrar cuánto te dura.
3. Prueba primero la tool con una herramienta HTTP. Antes de conectar nada a la plataforma de voz, manda a tu webhook de n8n el payload exacto que la plataforma enviaría, desde cualquier cliente HTTP, y confirma que la respuesta tiene la forma correcta. Eso descarta la mitad de los problemas sin gastar un minuto de conversación.
4. Un solo número, y compartido, si llegas a necesitar telefonía. No compres uno por cada experimento.

Errores comunes

Conectar el sistema multi-agente del Módulo 5 como tool de voz (conceptual). Qué pasa: alguien expone su triage_agent completo —con sus dos especialistas y sus bucles— como una tool de Vapi, porque es el agente que ya funciona. La llamada de prueba produce entre ocho y quince segundos de silencio absoluto en medio de la conversación, y a veces un tiempo de espera agotado. Por qué pasa: un sistema multi-agente hace varias llamadas al modelo en serie, y eso es correcto en chat y catastrófico en voz. Cómo detectarlo: mide cuánto tarda tu workflow en responder ejecutándolo con datos fijos; si pasa de dos segundos, no es una tool de voz. Cómo corregirlo: expón las tools de dominio —lookup_order, lookup_charge— directamente como funciones del agente de voz, y deja que el razonamiento lo haga el modelo de la plataforma. El sistema multi-agente es para los canales de texto, donde el tiempo se puede maquillar con un "escribiendo…".

Devolver JSON crudo y esperar que suene bien (práctico). Qué pasa: la tool devuelve {"status":"in_transit","eta":"2026-07-23"} y el agente dice cosas como "el estado es in transit y el i-t-a es dos mil veintiséis guion cero siete guion veintitrés". Por qué pasa: el modelo tiene que traducir datos a habla, y a veces lo hace y a veces no, sobre todo con valores técnicos y fechas en formato ISO. Cómo detectarlo: es audible de inmediato en la primera llamada de prueba. Cómo corregirlo: devuelve texto ya redactado para ser dicho, preparado en el workflow. Es trabajo del adaptador y hace la respuesta consistente en todas las corridas, no solo en las que el modelo tuvo suerte.

Olvidar el toolCallId en la respuesta a Vapi (práctico). Qué pasa: el workflow de n8n corre perfecto, se ve la ejecución exitosa en el registro, y el agente de voz se queda mudo o dice que no pudo obtener la información. Por qué pasa: Vapi empareja respuestas con llamadas por ese identificador; sin él, tu respuesta no corresponde a nada y se descarta. Cómo detectarlo: ejecución exitosa en n8n y silencio en la llamada es la firma exacta de este error. Cómo corregirlo: guarda el id de la llamada al principio del workflow y devuélvelo idéntico en el campo toolCallId. Y confirma la ruta hasta él contra un payload real, porque la estructura anidada de Vapi es fácil de escribir mal.

No activar el "hablar mientras espera" (práctico). Qué pasa: la tool tarda dos segundos, que es un tiempo perfectamente razonable, y la persona escucha dos segundos de silencio total en medio de una frase. Mucha gente dice "¿hola?" o cuelga. Por qué pasa: en chat, dos segundos son invisibles; en voz, son largos, y la opción que lo resuelve está apagada por defecto en algunas configuraciones. Cómo detectarlo: hazte una llamada y escúchate esperando. Cómo corregirlo: activa la opción correspondiente (Speak During Execution en Retell, el equivalente en las otras) y escribe una frase de espera corta y natural. Y no pongas una frase larga: si la tool responde en 800 milisegundos, una frase de espera de tres segundos empeora la experiencia en vez de mejorarla.

Dejar el webhook de la tool abierto sin ninguna verificación (práctico). Qué pasa: el endpoint de lookup_order queda accesible en internet sin autenticación, y cualquiera que descubra la URL puede consultar el estado de cualquier pedido probando números. Por qué pasa: durante el desarrollo uno quita la autenticación para que funcione a la primera y se olvida de volver a ponerla. Cómo detectarlo: llama a tu webhook desde una terminal sin ninguna cabecera; si responde con datos, está abierto. Cómo corregirlo: como mínimo, una cabecera con un secreto compartido configurada en la plataforma de voz y verificada en n8n; y en Retell, además, la verificación de la firma X-Retell-Signature. El tratamiento serio de límites de confianza es el Módulo 7, pero un endpoint sin ninguna verificación no debería llegar vivo hasta allá.

Ejercicios

Ejercicio 1 — Traduce una tool a voz. Toma la tool check_return_eligibility del Módulo 5, que dado un pedido devuelve si la devolución procede y hasta qué fecha. Escribe: (a) su Description para un agente de voz, incluyendo la instrucción sobre datos faltantes; (b) los tres resultados posibles como texto listo para ser dicho, en vez de como JSON; (c) qué debe hacer el agente si el reconocimiento no captó bien el número de pedido.

Name: check_return_eligibility
Description:
  Determina si un pedido de TuTienda todavía está dentro del plazo
  para devolución y hasta qué fecha. Úsala cuando el cliente diga
  que quiere devolver, cambiar o regresar un producto.
  No sirve para cobros ni para consultar el estado de un envío.
  Requiere el número de pedido. Si el cliente no lo dio o no lo
  entendiste con claridad, pídeselo dígito por dígito y confírmalo
  antes de llamar a esta herramienta. Nunca lo inventes ni lo
  deduzcas de una conversación anterior.

Procede:
  "Sí, todavía puedes devolverlo. Tienes hasta el domingo tres
   de agosto."

No procede por plazo:
  "El plazo para devolver ese producto ya pasó. Era de catorce
   días porque es electrónico."

No aplica (categoría sin devolución):
  "Ese producto no admite devolución por su categoría. Puedo
   pasarte con alguien del equipo si quieres revisarlo."

Ejercicio 2 — Elige la arquitectura. Para cada uno de estos cuatro casos de TuTienda, di si usarías la arquitectura A (plataforma como cerebro, n8n como tool) o la B (n8n como cerebro), y justifica en una línea.

1. Un número al que los clientes llaman para consultar el estado de su pedido.
2. Un flujo que procesa los mensajes de voz que los clientes mandan por WhatsApp.
3. Un agente que llama a clientes con carritos abandonados para ofrecerles ayuda.
4. Un buzón de voz que transcribe el mensaje y crea un ticket con la petición.

Ejercicio 3 — Construye y mide. Monta la tool lookup_order como webhook en n8n siguiendo el ejemplo trabajado, pero no la conectes todavía a ninguna plataforma de voz. En cambio: (a) manda a tu webhook, con un cliente HTTP, el payload exacto que mandaría Vapi, y confirma que la respuesta tiene la forma correcta con el toolCallId emparejado; (b) mide cuánto tarda el workflow de punta a punta, ejecutándolo cinco veces; (c) di si ese número es aceptable para voz y qué harías si no lo fuera.

{
  "message": {
    "type": "tool-calls",
    "toolCallList": [
      { "id": "test_001", "name": "lookup_order",
        "arguments": { "order_id": "4521" } }
    ]
  }
}

{ "results": [ { "toolCallId": "test_001",
                 "result": "El pedido va en camino y llega aproximadamente el jueves veintitrés de julio." } ] }

Resumen y siguiente paso

Ya sabes qué hay dentro de un agente de voz: una cadena de reconocimiento, modelo y síntesis, gobernada por un director de turnos que decide cuándo alguien terminó de hablar y si puede interrumpir. Y sabes cuál es el número que manda: el presupuesto de latencia, donde el único componente que tus decisiones mueven de verdad son las herramientas que el agente llama. De ahí sale la arquitectura correcta —la plataforma conduce, n8n es la mano— y de ahí sale también por qué el sistema multi-agente del Módulo 5 no se conecta directo a una llamada telefónica.

Aprendiste el patrón concreto en las tres plataformas: una función con nombre y descripción, un webhook de n8n como destino, parámetros declarados y un resultado devuelto — con las particularidades de cada una, el toolCallId emparejado de Vapi, la firma y las variables de respuesta de Retell, y los tipos de valor de ElevenLabs que permiten sacar un dato del ámbito de la interpretación del modelo. Escribiste un prompt de voz, que es otro prompt: dos frases, sin listas, sin formato, números como los diría una persona, confirmación antes de actuar y un plan explícito para cuando no se entiende. Y viste que n8n vuelve al centro cuando la llamada termina, con el webhook de fin de llamada que registra, clasifica, crea el ticket y manda por WhatsApp el enlace que por teléfono era imposible de dar.

Antes de avanzar deberías poder: explicar en una frase por qué la arquitectura A domina en telefonía y en qué caso concreto B es correcta; nombrar las tres formas de que un silencio de dos segundos no se note en una llamada; y decir por qué una tool de voz debe devolver texto redactado en vez de JSON.

La lección 6 toma lo que acabas de ver en voz —que la misma información se dice distinto según el canal— y lo convierte en un método para los cuatro. Longitud, formato, botones, asincronía y el ritmo de cada canal, con la misma respuesta del agente escrita cuatro veces y una regla clara sobre dónde vive esa adaptación: en el adaptador, nunca en el cerebro.

Recursos

• Custom tools — Vapi Docs — la configuración de una function tool, la forma exacta del payload toolCallList y de la respuesta results con toolCallId.
• Custom functions — Retell AI Docs — todos los campos de una custom function, incluidos Speak During Execution, Response Variables y el tope de caracteres de la respuesta.
• Retell AI + n8n — el nodo de comunidad @retellai/n8n-nodes-retellai para disparar llamadas salientes desde un workflow.
• ElevenLabs Agents — tools — las webhook tools, sus tipos de parámetro y la distinción entre valor por prompt del modelo y variable dinámica.
• Webhook node — n8n Docs — el nodo que es el puente real con las tres plataformas, con sus opciones de autenticación por cabecera.
• Respond to Webhook node — n8n Docs — cómo devolver exactamente el JSON que cada plataforma espera, que es la mitad de esta lección.