En el módulo 7 cerramos la última pieza suelta: el VAD (Voice Activity Detection, detección de actividad de voz —saber cuándo hay alguien hablando) y el turn-taking (el reparto de turnos —decidir cuándo el usuario terminó de hablar y le toca responder al agente). Con eso ya tenemos, por separado, todo lo que hace falta: el ASR (Automatic Speech Recognition, reconocimiento de voz) que pasa audio a texto, el LLM (Large Language Model, el modelo de lenguaje) que decide qué responder, el TTS (Text-to-Speech, síntesis de voz) que devuelve el texto a audio, y el VAD y el turn-taking que gobiernan los turnos. Siete módulos juntando piezas. Este módulo hace lo que faltaba: ensamblarlas en un agente que conversa de verdad, en tiempo real, sin que el usuario perciba las costuras.

La tesis del módulo

Un agente de voz es un pipeline orquestado en tiempo real donde el LLM es solo una etapa; la arquitectura —cascada versus speech-to-speech— define la latencia, el costo, el control y hasta la personalidad del producto. No eliges “un modelo de voz”: eliges cómo se conectan cinco componentes, y esa decisión de plomería determina más de la experiencia que cualquier prompt que escribas después.

La arquitectura en cascada

La forma clásica —y todavía la más usada— encadena tres modelos especializados en serie. El audio entra, se transcribe a texto, el texto se piensa, la respuesta se sintetiza a audio. Cascada (cascade, en cascada) porque cada etapa alimenta a la siguiente y la salida de una es la entrada de la otra. Entre esas etapas viven el VAD y el turn-taking, que no transforman el contenido pero deciden cuándo arranca cada paso.

        PIPELINE EN CASCADA DE UN AGENTE DE VOZ

 usuario habla
      │
      ▼
 ┌──────────┐   ¿hay voz?    ┌──────────┐
 │   VAD    │ ────────────►  │   ASR    │
 │ (turnos) │   ¿terminó?    │  (STT)   │
 └──────────┘                └────┬─────┘
      ▲                           │ texto
      │ interrupción              ▼
      │                      ┌──────────┐
      │                      │   LLM    │ ──► tools
      │                      │ (decide) │ ◄──
      │                      └────┬─────┘
      │                           │ texto
      │                           ▼
      │                      ┌──────────┐
      └──────────────────────│   TTS    │
         barge-in corta      │ (audio)  │
         el TTS              └────┬─────┘
                                  ▼
                            agente habla

Fíjate en el detalle que el diagrama deja ver: el VAD no está solo al principio. La flecha de la izquierda es la interrupción (barge-in, cuando el usuario habla encima del agente): mientras el TTS reproduce, el VAD sigue escuchando, y si detecta voz corta la síntesis y devuelve el control. Esa flecha de retorno es la diferencia entre un agente que conversa y un contestador que recita.

Las ventajas de la cascada son concretas. Control total: puedes cambiar el ASR sin tocar el LLM, o el LLM sin tocar el TTS, porque hablan por texto. Cualquier LLM: no dependes de que el proveedor haya sacado un modelo de voz; usas el mejor modelo de texto que exista hoy. Tools: el LLM es uno de texto normal, así que llama funciones exactamente como cualquier agente de texto. Y texto para logs y evals: cada turno deja una transcripción legible que puedes revisar, versionar y evaluar. Esa observabilidad es gratis en la cascada y cara en la alternativa.

La desventaja es igual de concreta y es una sola idea con dos caras. La primera cara es la latencia acumulada: son tres modelos en serie, y el tiempo total es la suma de los tres más el trasiego de datos entre ellos. La segunda cara es más sutil: al pasar por texto, se pierde la prosodia del audio original (prosody, la melodía del habla —tono, ritmo, énfasis, emoción). El ASR entrega las palabras pero no que el usuario las dijo con rabia, con duda o con sarcasmo. El LLM decide a ciegas sobre ese matiz, y el TTS lo reinventa desde cero. La cascada oye lo que se dijo, no cómo se dijo.

La alternativa: speech-to-speech

La otra arquitectura elimina las etapas intermedias. Un solo modelo multimodal recibe audio y devuelve audio, sin pasar nunca por texto. Speech-to-speech (habla a habla, o audio nativo): el modelo “oye” y “habla” directamente, como una persona. Al no cruzar la frontera del texto, conserva el tono y la emoción del audio de entrada, y al ser un solo paso en vez de tres, la latencia es sensiblemente menor.

El precio es el espejo de las ventajas de la cascada. Menos control: el modelo es una caja negra de audio a audio; no puedes cambiarle el ASR ni el TTS porque no los tiene por separado. Más difícil de instrumentar y auditar: no hay transcripción natural de cada turno, así que evaluar, loguear y depurar cuesta más trabajo. Esta arquitectura se profundiza en el módulo 9; aquí basta con contrastarla para entender qué se gana y qué se cede.

Criterio	Cascada (STT→LLM→TTS)	Speech-to-speech
Latencia	Alta (tres modelos en serie)	Baja (un solo paso)
Control	Total: cada etapa es reemplazable	Bajo: caja negra audio→audio
Costo	Tres facturas, más plomería	Una factura, suele salir más
Tools	Nativas (LLM de texto normal)	Soportadas, pero más nuevas
Prosodia	Se pierde al pasar por texto	Se conserva (tono, emoción)
Observabilidad	Alta: transcripción en cada turno	Baja: no hay texto natural

La tabla no tiene un ganador: tiene un eje. A la izquierda del eje mandan el control y la auditabilidad; a la derecha, la latencia y la naturalidad. Un agente de soporte con muchas tools y requisitos de cumplimiento vive a la izquierda; una compañía conversacional que debe sonar humana vive a la derecha. La arquitectura es la decisión de producto, no un detalle técnico.

Dónde encajan las tools

En la cascada, el LLM es un modelo de texto corriente, así que las tools (herramientas, funciones que el agente puede invocar —consultar una base de datos, agendar, cobrar) funcionan igual que en un agente de texto: el modelo emite una llamada a función, el orquestador la ejecuta, le devuelve el resultado, y el modelo sigue. Todo el mecanismo de cómo funciona un agente aplica sin cambios.

Sin cambios en la mecánica, pero con una presión nueva encima: la latencia. En un agente de texto, una tool que tarda dos segundos es un spinner; el usuario espera mirando la pantalla. En voz, dos segundos de silencio absoluto es un abismo —el usuario cree que se cortó la llamada, dice “¿hola?” y arruina el turno. Una tool lenta no ralentiza la conversación de voz: la mata.

Ojo: en voz no puedes esconder la latencia de una tool detrás de un indicador de carga; el único canal es el audio, y el silencio se interpreta como falla. El manejo de la espera es parte del diseño, no un extra.

El patrón que resuelve esto es el relleno verbal (filler, muletilla de espera): antes de invocar la tool, el agente dice algo natural —“déjame revisar eso”, “un segundo que lo busco”— y recién entonces la ejecuta. El relleno compra tiempo sin mentir y suena humano porque es lo que una persona haría. Variante avanzada: emitir el relleno mientras la tool corre en paralelo, no antes, para no sumar su duración a la espera. La regla de fondo es que en voz el agente nunca puede quedarse callado esperando; siempre debe estar produciendo audio o escuchando.

Gestión de estado y contexto

Una conversación hablada es más caótica que un chat, y el agente tiene que llevar la cuenta de ese caos. El estado (state, la memoria viva de la conversación) incluye al menos tres cosas que en texto casi no dan problema:

El historial de turnos. Igual que en texto, pero construido a partir de transcripciones del ASR, que traen errores. Un nombre mal transcrito se arrastra por toda la conversación si no se corrige.
Los turnos a medias. Una interrupción deja un turno incompleto: el agente dijo la mitad de una frase antes de que lo cortaran. ¿Qué guardas en el historial —lo que alcanzó a decir, lo que iba a decir, nada? La respuesta correcta suele ser lo que efectivamente se reprodujo, porque es lo único que el usuario oyó.
Las correcciones sobre la marcha. “Reserva para el jueves… no, dije el martes.” En texto el usuario borra y reescribe; en voz corrige hablando, y el segundo turno contradice al primero. El agente tiene que entender que el martes gana, no agendar los dos días.

Estas tres no son casos borde: son el día a día del habla. Un agente que solo maneja turnos limpios y completos funciona en la demo y se rompe en la primera llamada real.

Frameworks de orquestación

Todo lo anterior —conectar cinco componentes, gestionar interrupciones, sincronizar audio por la red, llevar el estado— es plomería difícil y repetitiva. Por eso casi nadie la escribe a mano: se usa un framework de orquestación (orchestration framework, la capa que cablea los componentes y maneja el tiempo real). Lo que un framework resuelve por ti es el transporte (transport, mover el audio entre el usuario y el servidor, típicamente por WebRTC —el protocolo de audio en tiempo real del navegador), el VAD, las interrupciones y toda la coordinación temporal entre etapas.

Opción	Qué es	Cuándo usarla
Pipecat	Framework open source en Python; pipeline de frames (paquetes de datos) que atraviesan procesadores intercambiables	Quieres control total del stack y self-hosting
LiveKit Agents	Framework open source sobre WebRTC; el agente entra a una “sala” como un participante más	Necesitas transporte robusto y escala en red inestable
Vapi	Plataforma gestionada, orientada a desarrolladores; API con control fino del stack	Quieres control de componentes sin operar infraestructura
Retell	Plataforma gestionada llave en mano; telefonía y cumplimiento incluidos	Quieres un agente telefónico en producción rápido

La diferencia de fondo entre las dos primeras y las dos últimas es el eje construir-versus-comprar. Pipecat te da los ladrillos: defines la secuencia transporte → STT → LLM → TTS como una lista de procesadores y el framework enruta los frames, maneja la contrapresión y corta el TTS en una interrupción. LiveKit Agents aporta lo mismo pero montado sobre su infraestructura WebRTC, pensado para que el agente se comporte bien aun con la red del usuario fallando. Vapi y Retell son plataformas: pagas por minuto y te ahorras operar servidores, a cambio de menos control sobre las tripas y una factura que escala con el uso.

¿Cuándo armarlo a mano, sin framework? Casi nunca para producción. La plomería de tiempo real (sincronizar audio, cortar el TTS en el milisegundo justo, manejar la reconexión) es exactamente lo que un framework hace bien y lo que a ti te va a tomar meses hacer mal. Armarlo a mano tiene sentido para aprender cómo funciona por dentro —que es medio curso— o para un caso tan raro que ningún framework lo cubra.

Código: el esqueleto de un agente en Pipecat

Este es el esbozo de un pipeline de voz con Pipecat, a alto nivel. Muestra la idea central —una lista ordenada de procesadores por la que fluyen los frames— sin pretender ser ejecutable tal cual. Es ilustrativo: la forma exacta de importar y nombrar servicios cambia entre versiones, así que verifica contra la documentación de Pipecat antes de copiar.

"""Esqueleto ILUSTRATIVO de un agente de voz en cascada con Pipecat.

La idea que importa: el pipeline es una LISTA ORDENADA de procesadores.
Los frames (paquetes de audio/texto) entran por el transporte, atraviesan
STT → LLM → TTS y salen por el transporte. El framework se encarga del
VAD, las interrupciones y la sincronización temporal. Verifica los
nombres de import y servicios contra la doc oficial de tu versión: la
API cambia seguido (PipelineTask/PipelineRunner pasaron a llamarse
PipelineWorker/WorkerRunner en 2026).
"""
from pipecat.audio.vad.silero import SileroVADAnalyzer
from pipecat.pipeline.pipeline import Pipeline
from pipecat.pipeline.worker import PipelineParams, PipelineWorker
from pipecat.workers.runner import WorkerRunner

# 1. Transporte: mueve el audio por WebRTC entre el usuario y el agente.
#    Lleva el VAD (Silero): así el framework sabe cuándo hay voz y puede
#    cortar el TTS en un barge-in (las interrupciones vienen activadas).
transport = WebRTCTransport(params=TransportParams(
    audio_in_enabled=True,
    audio_out_enabled=True,
    vad_analyzer=SileroVADAnalyzer(),
))

# 2. Las tres etapas de la cascada. Cada una es un servicio
#    reemplazable: cambiar de proveedor no toca el resto del pipeline.
stt = SttService(api_key=...)          # audio  → texto
llm = LlmService(model="gpt-4o",       # texto  → texto (+ tools)
                 tools=mis_tools)
tts = TtsService(voice="es-neutral")   # texto  → audio

# 3. El pipeline: una lista ordenada. Los frames fluyen de arriba
#    a abajo. transport.input() entrega audio; transport.output()
#    reproduce la respuesta al usuario.
pipeline = Pipeline([
    transport.input(),   # audio entrante del usuario
    stt,                 # lo transcribe
    llm,                 # decide qué responder (y llama tools)
    tts,                 # sintetiza la respuesta a voz
    transport.output(),  # audio saliente hacia el usuario
])

# 4. El worker envuelve el pipeline con sus parámetros de audio.
worker = PipelineWorker(pipeline, params=PipelineParams(
    audio_in_sample_rate=16000,
    audio_out_sample_rate=24000,
))

# 5. El runner arranca el bucle de tiempo real y lo mantiene vivo.
await WorkerRunner().run(worker)

Lee ese pipeline de arriba abajo y tienes la lección entera del módulo en diez líneas: el agente es esa lista. Cambiar la personalidad del producto es cambiar el llm; cambiar la voz es cambiar el tts; migrar a speech-to-speech es reemplazar las tres etapas del medio por un único servicio de audio a audio. La arquitectura no es un diagrama en una pizarra: es literalmente el orden de esa lista.

Errores comunes

Tratar el LLM como si fuera el agente. El LLM es una etapa de cinco. La latencia, las interrupciones y el estado —lo que hace que el agente se sienta vivo— viven en el orquestador, no en el modelo. Un prompt perfecto sobre una plomería mala es un agente malo.
Ignorar la latencia de las tools. Una tool que en un chatbot pasa desapercibida, en voz produce un silencio que el usuario lee como falla. Sin relleno verbal ni ejecución en paralelo, cada tool lenta rompe un turno.
No manejar las interrupciones. Un agente que no se deja cortar no conversa: recita. El barge-in que devuelve el turno no es un lujo, es el umbral mínimo para que suene humano.
Guardar mal los turnos a medias. Si en el historial anotas lo que el agente “iba a decir” en vez de lo que efectivamente se reprodujo, el contexto se desincroniza con lo que el usuario oyó, y las respuestas siguientes salen desalineadas.
Elegir speech-to-speech por moda. Es más natural y más rápido, pero pierdes control y observabilidad. Si tu producto tiene muchas tools y requisitos de auditoría, la cascada suele ser la decisión correcta, aunque suene menos glamorosa.
Armar la plomería a mano para producción. Sincronizar audio y cortar el TTS en el instante justo es precisamente lo que un framework resuelve. Reescribirlo es gastar meses en volver a inventar Pipecat, peor.

La frase para llevarse

“Un agente de voz no es un modelo, es una lista ordenada de componentes corriendo en tiempo real. La arquitectura —cascada o speech-to-speech— es la decisión de producto; el prompt viene después.”

Qué viene

Módulo 9: speech-to-speech y las Realtime APIs. Contrastamos aquí la cascada con el audio nativo; en el próximo módulo entramos de lleno en la alternativa. Cómo funciona un modelo que oye y habla sin pasar por texto, qué son las Realtime APIs que exponen los proveedores, cómo se conectan las tools cuando no hay una etapa de texto donde engancharlas, y la pregunta honesta que cierra la comparación: para tu producto concreto, ¿la latencia y la naturalidad del audio nativo compensan lo que pierdes en control y observabilidad?

Voz e IA — Módulo 8: la arquitectura de un agente de voz