Construir un agente de voz parece sencillo hasta que deja de ser una demostración.
En una demo controlada, el usuario formula una pregunta clara, espera su turno y escucha una respuesta preparada en condiciones razonables de red. En una conversación real ocurre lo contrario: las personas hacen pausas a mitad de una frase, interrumpen, cambian de opinión mientras hablan, utilizan nombres propios, llaman desde conexiones deficientes y esperan que el sistema consulte aplicaciones empresariales sin introducir silencios incómodos.
Es ahí donde la calidad de un agente deja de depender únicamente del modelo de inteligencia artificial o de lo natural que resulte una voz sintética. Entre el momento en que una persona empieza a hablar y el instante en que escucha una respuesta interviene una cadena completa de componentes: transporte de audio, detección de actividad, reconocimiento de voz, identificación del final de turno, contexto, modelo de lenguaje, herramientas, síntesis de voz y nuevamente transporte. Cada eslabón puede introducir latencia, errores o dependencia tecnológica.
Por eso iniciamos esta investigación con una comparación aparentemente sencilla: Pipecat vs. ElevenLabs. La pregunta era qué ventajas y desventajas tenía construir agentes de voz utilizando Pipecat frente a una solución como ElevenLabs. La investigación obligó a modificar la pregunta.
Pipecat y ElevenLabs no ocupan exactamente la misma capa tecnológica y, de hecho, pueden utilizarse juntos. Al ampliar el análisis apareció LiveKit Agents como un competidor arquitectónico mucho más directo de Pipecat, mientras que ElevenAgents, Vapi y Retell representan diferentes maneras de comprar como servicio una parte mayor del problema.
La decisión relevante, por tanto, no es solamente qué proveedor elegir. Es qué partes de la arquitectura conversacional conviene construir, cuáles conviene consumir como servicio y cuánto control necesita conservar una empresa sobre cada una de ellas.
Antes de comparar productos, hay que entender el pipeline
Un agente de voz basado en un pipeline tradicional puede representarse, de manera simplificada, así:
Usuario → audio → detección de turno → STT → LLM → herramientas → TTS → audio → usuario
STT (speech-to-text) convierte la voz en texto. El modelo de lenguaje interpreta la conversación y decide qué responder o qué acción ejecutar. Las herramientas permiten consultar o modificar sistemas externos. Finalmente, TTS (text-to-speech) convierte la respuesta nuevamente en voz.
La simplificación es útil, pero oculta parte de la dificultad. Estos componentes no necesariamente trabajan de manera estrictamente secuencial. Los sistemas orientados a tiempo real intentan procesar información mediante streaming, anticipar operaciones y solapar etapas para reducir el tiempo que percibe el usuario.
Además, existe otro enfoque: los modelos speech-to-speech o realtime pueden recibir y producir audio directamente, reduciendo algunas de las fronteras tradicionales del pipeline. Esto puede mejorar determinados aspectos de la conversación, aunque también modifica las posibilidades de control, observabilidad, selección de proveedores y estructura de costos.
Por tanto, antes de elegir una plataforma hay una primera decisión arquitectónica: pipeline componible, modelo realtime o una combinación de ambos.
Pipecat: tratar la conversación como una arquitectura componible
Pipecat es un framework open source en Python, distribuido bajo licencia BSD 2-Clause, orientado a aplicaciones conversacionales de voz y sistemas multimodales. Su característica más importante no es que incluya un determinado modelo de voz. Es precisamente lo contrario: el framework está diseñado para que las diferentes piezas del pipeline puedan combinarse y sustituirse.
Una implementación puede utilizar un proveedor para STT, otro para el LLM y ElevenLabs para TTS. Puede cambiar posteriormente alguno de ellos sin que eso implique necesariamente reconstruir toda la aplicación. La documentación de Pipecat mantiene un catálogo amplio de integraciones para modelos, voz, transportes y servicios.
Esta separación resulta particularmente valiosa en un mercado donde la ventaja relativa de los modelos cambia con rapidez. El proveedor que hoy ofrece la mejor combinación de precisión, latencia y costo para reconocimiento de español no tiene por qué seguir siendo el mismo dentro de doce meses.
La modularidad, sin embargo, no debe confundirse con simplicidad. Cuando una organización utiliza Pipecat obtiene control sobre una parte considerable de la arquitectura, pero también asume la responsabilidad de diseñarla. El equipo debe decidir cómo desplegar los agentes, cómo manejar fallas, cómo observar cada etapa, qué componentes utilizar, cómo escalar la infraestructura y qué comportamiento adoptar cuando alguno de los proveedores externos deja de responder.
En otras palabras, Pipecat no elimina complejidad. Permite decidir dónde colocarla.
LiveKit Agents cambia el mapa competitivo
Al estudiar alternativas apareció un resultado que modifica sustancialmente la comparación original. Si la pregunta es qué framework permite construir mediante código una arquitectura de agentes de voz altamente configurable, LiveKit Agents es uno de los competidores que deben evaluarse junto con Pipecat.
LiveKit Agents es open source y soporta Python y Node.js. Permite construir pipelines STT-LLM-TTS, utilizar modelos realtime, incorporar herramientas y administrar turnos e interrupciones. Su origen arquitectónico está ligado a comunicaciones realtime y WebRTC: los agentes participan en salas como participantes programáticos y el framework incorpora infraestructura para ejecutar y escalar agentes.
Esto crea una propuesta interesante para producción: conservar una cantidad importante de control mediante código sin tener que diseñar desde cero toda la infraestructura de medios y sesiones realtime. LiveKit Cloud añade además observabilidad administrada. La comparación Pipecat-LiveKit, por tanto, no produce un ganador evidente: Pipecat resulta especialmente atractivo cuando el pipeline conversacional debe ser una pieza extremadamente componible; LiveKit gana interés cuando, además del pipeline, la organización quiere resolver dentro del mismo ecosistema una parte importante de WebRTC, sesiones realtime e infraestructura de agentes.
ElevenLabs: de proveedor de voz a plataforma de agentes
ElevenLabs requiere una lectura distinta. Compararlo directamente con Pipecat como si fueran productos equivalentes conduce a conclusiones engañosas.
ElevenAgents coordina actualmente reconocimiento de voz, un LLM seleccionado o personalizado, síntesis de voz y un modelo propietario encargado del turn-taking. Sobre esa arquitectura incorpora workflows, herramientas, testing, evaluaciones, experimentos, analytics y gestión de conversaciones.
La propuesta es reducir el número de decisiones que un equipo necesita resolver para colocar un agente en producción. Eso tiene un valor económico y operativo real. Cada componente que una plataforma administra es una pieza menos que el equipo interno necesita implementar, integrar, observar y mantener.
La contrapartida es que una mayor proporción de la arquitectura queda expresada mediante las abstracciones de la plataforma. Esto no significa que ElevenAgents sea completamente cerrado: permite seleccionar modelos y utilizar LLM personalizados. La diferencia es más sutil: configurar componentes dentro de una plataforma no equivale a ser propietario del mecanismo que los orquesta.
Pipecat y ElevenLabs no tienen por qué competir
Esta fue una de las conclusiones más útiles de la investigación. Pipecat cuenta con integración oficial con ElevenLabs TTS. Es posible utilizar Pipecat para administrar el pipeline, transporte, contexto, herramientas y lógica conversacional mientras ElevenLabs se ocupa únicamente de sintetizar la voz.
Una arquitectura podría utilizar, por ejemplo, un STT seleccionado específicamente por su desempeño en español, un modelo de lenguaje diferente, herramientas conectadas con CRM o ERP y ElevenLabs para generar el audio.
La decisión deja entonces de ser “Pipecat o ElevenLabs” y se convierte en una pregunta arquitectónica más precisa: ¿en qué capas queremos utilizar ElevenLabs y en cuáles queremos conservar independencia?
Vapi: abstraer infraestructura sin ocultar completamente los componentes
Vapi ocupa una posición intermedia. Su propuesta está estructurada alrededor de componentes como transcriber, model y voice, permitiendo combinar distintos proveedores mientras la plataforma se encarga de una parte considerable de la infraestructura de llamadas y orquestación.
Esta estructura tiene una ventaja para equipos que quieren reducir trabajo de infraestructura sin convertir la selección de modelos en una decisión completamente monolítica. También muestra por qué el precio anunciado por minuto debe interpretarse con cuidado: la tarifa de plataforma no representa necesariamente el costo completo de la conversación; representa una capa de la arquitectura.
Retell: cuando el problema comienza en el teléfono
Retell AI merece entrar en el análisis especialmente cuando el canal dominante es telefonía. Su propuesta integra infraestructura de voz, telefonía, modelos, síntesis, herramientas operativas, testing y analytics. Para casos como contact centers, reservaciones, calificación telefónica, soporte o procesos predominantemente PSTN, una plataforma de este tipo puede reducir considerablemente la cantidad de infraestructura que debe construir una empresa.
Una vez más aparece el mismo intercambio: menos ingeniería propia a cambio de aceptar una mayor dependencia de las abstracciones y economía de la plataforma.
El verdadero enemigo de la conversación: la latencia acumulada
Hasta aquí hemos hablado de arquitectura. Pero el usuario no percibe frameworks ni pipelines. Percibe una conversación, y una conversación se deteriora rápidamente cuando sus tiempos dejan de parecer humanos.
El error habitual es hablar de “la latencia” del agente como si fuera una sola cifra. En un pipeline tradicional, lo que el usuario experimenta es aproximadamente la suma —y, cuando existe procesamiento concurrente, la superposición— de varios tiempos:
detección del final del turno + STT + razonamiento + herramientas + inicio del TTS + transporte
Esto explica por qué seleccionar el LLM más rápido no garantiza el agente más rápido. Si el sistema tarda demasiado en decidir que el usuario terminó de hablar, una parte importante del presupuesto de latencia ya se perdió antes de consultar el modelo. Lo mismo ocurre con las herramientas: una consulta empresarial que tarda varios segundos puede ser aceptable en un proceso batch y resultar intolerable dentro de una conversación.
Por eso conviene tratar la latencia como un presupuesto distribuido entre componentes, no como un benchmark único de plataforma.
Turn-taking: donde muchos agentes dejan de parecer humanos
Una persona no termina cada frase y espera disciplinadamente una respuesta. Hace pausas, piensa, se corrige, respira, introduce muletillas y a veces deja una oración suspendida antes de completarla. Un VAD puede detectar que alguien dejó de emitir voz. Eso no significa necesariamente que haya terminado su idea.
Los frameworks actuales intentan resolver esta diferencia combinando señales acústicas con modelos capaces de estimar si un turno está semánticamente completo. Pipecat aborda el problema mediante Smart Turn junto con VAD; LiveKit ofrece estrategias de detección de turno y configuración de interrupciones; ElevenAgents incorpora un modelo propietario de turn-taking.
La consecuencia práctica es importante: comparar agentes exclusivamente por STT, LLM y TTS deja fuera uno de los componentes que más influye en la sensación de naturalidad.
Las interrupciones merecen métricas propias
Cuando el usuario comienza a hablar mientras el agente está respondiendo, el sistema debería detectar una interrupción legítima y detenerse con rapidez. Pero tampoco debería cortar su respuesta cada vez que escucha ruido, una respiración o una breve señal de asentimiento.
Una detección demasiado agresiva puede aumentar las falsas interrupciones. Una detección demasiado conservadora hace que el agente hable encima del usuario. Por ello, una prueba seria debería medir por separado el tiempo para detectar una interrupción, el tiempo efectivo hasta detener el audio, la proporción de interrupciones legítimas reconocidas y la tasa de falsos positivos.
El transporte también forma parte de la experiencia
Otro error frecuente consiste en considerar WebRTC o WebSocket como decisiones puramente de infraestructura. En aplicaciones web y móviles, WebRTC fue diseñado específicamente para transportar medios en tiempo real bajo condiciones variables de red. WebSocket sobre TCP puede ser adecuado para determinados escenarios server-to-server y es habitual en integraciones de telefonía, pero utilizarlo como sustituto universal de WebRTC puede trasladar complejidad a otras partes de la aplicación.
Para un agente que vive principalmente en navegador o móvil, WebRTC debería ser el punto de partida de la evaluación. Para telefonía o comunicación entre servidores, la respuesta puede ser distinta.
Observabilidad: saber que el agente falló no es suficiente
En producción aparecerá inevitablemente una conversación que “se sintió lenta”. Ese diagnóstico no sirve si el sistema no puede explicar dónde se perdió el tiempo: reconocimiento, LLM, CRM, TTS, red o detección del turno.
Una arquitectura de voz debería instrumentar esas etapas desde el principio. Pipecat ofrece integración con OpenTelemetry para observar diferentes componentes del pipeline. LiveKit Cloud concentra transcripciones, traces, logs y audio dentro de una línea temporal de sesión. ElevenAgents incorpora analytics, testing, evaluaciones y experimentos en la propia plataforma.
TTFB importa, pero no debería convertirse en la métrica dominante
Time to first byte es útil para saber cuánto tarda un componente en empezar a producir salida. Sin embargo, optimizar exclusivamente TTFB puede producir un agente técnicamente rápido y operacionalmente mediocre.
La evaluación necesita al menos tres capas. En la capa técnica interesa medir latencia end-to-end, STT, LLM TTFB, tool latency, TTS TTFB, errores, reconexiones e interrupciones. En la capa conversacional interesan repeticiones, solicitudes de aclaración, silencios anormales, falsos cortes, abandono y transferencias. Finalmente está el resultado del proceso: si el agente existe para reservar una cita, resolver una solicitud o calificar una oportunidad, la medición debe llegar hasta ese resultado.
Privacidad: el diagrama de datos importa más que la etiqueta del producto
Existe una tentación de simplificar la comparación como “open source significa privacidad” y “SaaS significa enviar los datos a terceros”. La arquitectura real es más complicada.
Un deployment con Pipecat o LiveKit puede ofrecer un alto grado de control sobre infraestructura y procesamiento, pero ese control también convierte a la organización en responsable de configurar y proteger correctamente el sistema. Las plataformas administradas ofrecen diferentes mecanismos de retención y privacidad. ElevenLabs, por ejemplo, documenta configuraciones de retención y Zero Retention Mode, además de opciones privadas para determinados clientes empresariales.
La pregunta útil no es únicamente dónde corre el framework. Es por dónde viajan los datos: audio → transporte → STT → modelo → herramientas → TTS → logs → analytics → almacenamiento.
El costo por minuto es una comparación incompleta
Los precios publicados parecen ofrecer una forma sencilla de ordenar plataformas. En realidad, sus modelos comerciales son suficientemente distintos como para que la comparación directa resulte engañosa. Un framework open source no tiene una tarifa única por conversación: hay que sumar infraestructura y todos los servicios utilizados. En plataformas administradas, la tarifa base puede excluir modelos, telefonía u otros componentes.
Esto sugiere una ecuación más útil:
TCO = infraestructura + transporte + STT + LLM + TTS + telefonía + observabilidad + ingeniería + operación + soporte + costo de cambio
Una plataforma administrada puede parecer más cara por minuto y resultar más económica durante la etapa inicial porque elimina semanas de ingeniería. Un framework puede parecer más económico y resultar más costoso si la organización construye infraestructura que nunca se convierte en una ventaja competitiva. También puede ocurrir lo contrario a escala.
La pregunta económica correcta no es “¿cuánto cuesta un minuto?”. Es “¿cuánto cuesta poseer esta capacidad durante su vida útil?”
Entonces, ¿qué opción conviene?
| Si la prioridad dominante es… | Conviene investigar primero… |
|---|---|
| Control fino del pipeline | Pipecat |
| Open source + infraestructura realtime integrada | LiveKit Agents |
| Plataforma integrada alrededor de voz y agentes | ElevenAgents |
| Plataforma administrada conservando elección de proveedores | Vapi |
| Telefonía productizada | Retell |
| Arquitectura abierta utilizando voces ElevenLabs | Pipecat + ElevenLabs |
| Aplicaciones web/mobile realtime complejas | Pipecat y LiveKit |
| Reducir el tiempo inicial de ingeniería | ElevenAgents, Vapi o Retell |
La tabla sirve para crear una shortlist, no para tomar la decisión final. Variables como idioma, acento, calidad de red, volumen, canal, sistemas empresariales, privacidad, disponibilidad regional y capacidades del equipo pueden modificar el resultado.
Cómo probar antes de elegir
Una comparación tecnológica de este tipo debería terminar en un benchmark propio, no en una tabla encontrada en Internet. Tomaríamos dos o tres finalistas y construiríamos el mismo caso de uso, utilizando entre 20 y 50 conversaciones representativas. El conjunto debería contener no sólo el camino ideal, sino ruido, interrupciones, silencios, nombres propios, ambigüedad, errores del usuario, herramientas lentas y solicitudes fuera del alcance del agente.
Las mismas conversaciones deberían ejecutarse contra todas las arquitecturas finalistas. Mediríamos precisión de STT, latencia percibida, calidad del turn-taking, interrupciones, cumplimiento de tarea, errores de herramientas, naturalidad de voz, estabilidad, costo y esfuerzo operativo. Para México, además, las pruebas deberían realizarse con español mexicano real, nombres y direcciones locales, números telefónicos, correos electrónicos y condiciones tanto de móvil como de PSTN cuando corresponda.
Ese benchmark probablemente será más útil que cualquier ranking general de proveedores, porque la pregunta empresarial no es qué agente funciona mejor en una demostración del fabricante, sino qué arquitectura funciona mejor para nuestras conversaciones.
Recomendaciones si la arquitectura elegida utiliza Pipecat
La primera recomendación es preservar deliberadamente la modularidad que motivó la elección. Si las dependencias particulares de cada STT, LLM o TTS terminan distribuidas por toda la aplicación, la capacidad teórica de intercambiar proveedores pierde buena parte de su valor. Conviene mantener fronteras claras entre transporte, escucha, razonamiento, herramientas y síntesis.
La segunda es no comenzar construyendo algoritmos propios de turn-taking. Smart Turn combinado con VAD proporciona un baseline para probar conversaciones reales antes de ajustar parámetros o desarrollar lógica especializada. La optimización debería responder a evidencia obtenida en las conversaciones, no únicamente a preferencias del equipo.
En aplicaciones web o móviles, WebRTC debería evaluarse antes de utilizar WebSockets por comodidad de implementación. También conviene utilizar streaming en STT, generación y TTS siempre que los proveedores y el caso de uso lo permitan.
La instrumentación debería existir desde el primer prototipo serio. Inicio y final de turno, resultado del STT, LLM TTFB, latencia de herramientas, TTS TTFB, inicio real del audio, interrupciones, errores y consumo permiten explicar posteriormente por qué una conversación funciona o falla.
Las herramientas empresariales necesitan además un tratamiento particular. Una API lenta no sólo introduce latencia: cambia la dinámica conversacional. Puede ser necesario responder parcialmente, utilizar estados intermedios, establecer timeouts o escalar al usuario en lugar de mantener varios segundos de silencio.
Finalmente, las instrucciones del agente deberían escribirse para conversación y no trasladarse directamente desde un chatbot. En voz, las respuestas extensas tienen un costo cognitivo mayor. Las interacciones suelen funcionar mejor cuando el agente comunica una idea por turno, confirma de manera concisa y formula preguntas específicas.
La decisión final no es Pipecat contra ElevenLabs
La investigación comenzó buscando las ventajas y desventajas de Pipecat frente a ElevenLabs y terminó mostrando un problema diferente.
Pipecat y LiveKit representan dos maneras de conservar control considerable sobre la arquitectura. ElevenAgents, Vapi y Retell ofrecen distintos grados de abstracción para reducir la cantidad de infraestructura y operación que el equipo debe asumir. ElevenLabs, además, puede convertirse simplemente en el proveedor de voz dentro de una arquitectura construida con Pipecat.
Una empresa que intenta validar en pocas semanas si las llamadas automatizadas pueden resolver un proceso probablemente obtendrá poco valor construyendo prematuramente toda su infraestructura realtime. En ese escenario, comprar abstracción puede ser la decisión racional.
La situación cambia cuando la conversación se convierte en parte sustancial del producto, cuando las integraciones empresariales son profundas, cuando existen requisitos particulares de infraestructura o datos, o cuando se anticipa la necesidad de sustituir proveedores conforme evoluciona el mercado. Entonces el control arquitectónico empieza a adquirir valor económico.
La conclusión es menos cómoda que un ranking, pero más útil: no hay que comenzar preguntando qué plataforma de agentes de voz es mejor. Hay que decidir primero qué parte de la capacidad conversacional necesita controlar la organización y qué parte puede comprar como servicio.
Después de responder esa pregunta, Pipecat, LiveKit, ElevenLabs, Vapi y Retell dejan de parecer cinco productos haciendo lo mismo. Se convierten en cinco formas distintas de distribuir control, complejidad, costo y responsabilidad dentro de una arquitectura de voz.
Fuentes y documentación consultada
- Pipecat Documentation
- LiveKit Agents Documentation
- LiveKit: turn detection and interruptions
- ElevenAgents Documentation
- ElevenLabs: Zero Retention Mode
- Vapi Pricing
- Retell AI Pricing
Nota editorial: capacidades, disponibilidad y precios de plataformas de IA cambian con rapidez. Las características comerciales deben verificarse nuevamente antes de tomar una decisión de compra.
