Construir un agente de voz parece sencillo hasta que deja de ser una demostraci\u00f3n.<\/p>\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\u00f3n real ocurre lo contrario: las personas hacen pausas a mitad de una frase, interrumpen, cambian de opini\u00f3n mientras hablan, utilizan nombres propios, llaman desde conexiones deficientes y esperan que el sistema consulte aplicaciones empresariales sin introducir silencios inc\u00f3modos.<\/p>\n
Es ah\u00ed donde la calidad de un agente deja de depender \u00fanicamente del modelo de inteligencia artificial o de lo natural que resulte una voz sint\u00e9tica. 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\u00f3n de actividad, reconocimiento de voz, identificaci\u00f3n del final de turno, contexto, modelo de lenguaje, herramientas, s\u00edntesis de voz y nuevamente transporte. Cada eslab\u00f3n puede introducir latencia, errores o dependencia tecnol\u00f3gica.<\/p>\n
Por eso iniciamos esta investigaci\u00f3n con una comparaci\u00f3n aparentemente sencilla: Pipecat vs. ElevenLabs<\/strong>. La pregunta era qu\u00e9 ventajas y desventajas ten\u00eda construir agentes de voz utilizando Pipecat frente a una soluci\u00f3n como ElevenLabs. La investigaci\u00f3n oblig\u00f3 a modificar la pregunta.<\/p>\n Pipecat y ElevenLabs no ocupan exactamente la misma capa tecnol\u00f3gica y, de hecho, pueden utilizarse juntos. Al ampliar el an\u00e1lisis apareci\u00f3 LiveKit Agents como un competidor arquitect\u00f3nico mucho m\u00e1s directo de Pipecat, mientras que ElevenAgents, Vapi y Retell representan diferentes maneras de comprar como servicio una parte mayor del problema.<\/p>\n La decisi\u00f3n relevante, por tanto, no es solamente qu\u00e9 proveedor elegir. Es qu\u00e9 partes de la arquitectura conversacional conviene construir, cu\u00e1les conviene consumir como servicio y cu\u00e1nto control necesita conservar una empresa sobre cada una de ellas<\/strong>.<\/p>\n Un agente de voz basado en un pipeline tradicional puede representarse, de manera simplificada, as\u00ed:<\/p>\n Usuario \u2192 audio \u2192 detecci\u00f3n de turno \u2192 STT \u2192 LLM \u2192 herramientas \u2192 TTS \u2192 audio \u2192 usuario<\/strong><\/p>\n STT (speech-to-text<\/em>) convierte la voz en texto. El modelo de lenguaje interpreta la conversaci\u00f3n y decide qu\u00e9 responder o qu\u00e9 acci\u00f3n ejecutar. Las herramientas permiten consultar o modificar sistemas externos. Finalmente, TTS (text-to-speech<\/em>) convierte la respuesta nuevamente en voz.<\/p>\n La simplificaci\u00f3n es \u00fatil, pero oculta parte de la dificultad. Estos componentes no necesariamente trabajan de manera estrictamente secuencial. Los sistemas orientados a tiempo real intentan procesar informaci\u00f3n mediante streaming, anticipar operaciones y solapar etapas para reducir el tiempo que percibe el usuario.<\/p>\n Adem\u00e1s, existe otro enfoque: los modelos speech-to-speech<\/em> o realtime pueden recibir y producir audio directamente, reduciendo algunas de las fronteras tradicionales del pipeline. Esto puede mejorar determinados aspectos de la conversaci\u00f3n, aunque tambi\u00e9n modifica las posibilidades de control, observabilidad, selecci\u00f3n de proveedores y estructura de costos.<\/p>\n Por tanto, antes de elegir una plataforma hay una primera decisi\u00f3n arquitect\u00f3nica: pipeline componible, modelo realtime o una combinaci\u00f3n de ambos<\/strong>.<\/p>\n 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\u00edstica m\u00e1s importante no es que incluya un determinado modelo de voz. Es precisamente lo contrario: el framework est\u00e1 dise\u00f1ado para que las diferentes piezas del pipeline puedan combinarse y sustituirse.<\/p>\n Una implementaci\u00f3n 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\u00f3n. La documentaci\u00f3n de Pipecat mantiene un cat\u00e1logo amplio de integraciones para modelos, voz, transportes y servicios.<\/p>\n Esta separaci\u00f3n resulta particularmente valiosa en un mercado donde la ventaja relativa de los modelos cambia con rapidez. El proveedor que hoy ofrece la mejor combinaci\u00f3n de precisi\u00f3n, latencia y costo para reconocimiento de espa\u00f1ol no tiene por qu\u00e9 seguir siendo el mismo dentro de doce meses.<\/p>\n La modularidad, sin embargo, no debe confundirse con simplicidad. Cuando una organizaci\u00f3n utiliza Pipecat obtiene control sobre una parte considerable de la arquitectura, pero tambi\u00e9n asume la responsabilidad de dise\u00f1arla. El equipo debe decidir c\u00f3mo desplegar los agentes, c\u00f3mo manejar fallas, c\u00f3mo observar cada etapa, qu\u00e9 componentes utilizar, c\u00f3mo escalar la infraestructura y qu\u00e9 comportamiento adoptar cuando alguno de los proveedores externos deja de responder.<\/p>\n En otras palabras, Pipecat no elimina complejidad. Permite decidir d\u00f3nde colocarla.<\/strong><\/p>\n Al estudiar alternativas apareci\u00f3 un resultado que modifica sustancialmente la comparaci\u00f3n original. Si la pregunta es qu\u00e9 framework permite construir mediante c\u00f3digo una arquitectura de agentes de voz altamente configurable, LiveKit Agents es uno de los competidores que deben evaluarse junto con Pipecat<\/strong>.<\/p>\n 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\u00f3nico est\u00e1 ligado a comunicaciones realtime y WebRTC: los agentes participan en salas como participantes program\u00e1ticos y el framework incorpora infraestructura para ejecutar y escalar agentes.<\/p>\n Esto crea una propuesta interesante para producci\u00f3n: conservar una cantidad importante de control mediante c\u00f3digo sin tener que dise\u00f1ar desde cero toda la infraestructura de medios y sesiones realtime. LiveKit Cloud a\u00f1ade adem\u00e1s observabilidad administrada. La comparaci\u00f3n 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\u00e9s cuando, adem\u00e1s del pipeline, la organizaci\u00f3n quiere resolver dentro del mismo ecosistema una parte importante de WebRTC, sesiones realtime e infraestructura de agentes.<\/p>\n ElevenLabs requiere una lectura distinta. Compararlo directamente con Pipecat como si fueran productos equivalentes conduce a conclusiones enga\u00f1osas.<\/p>\n ElevenAgents coordina actualmente reconocimiento de voz, un LLM seleccionado o personalizado, s\u00edntesis de voz y un modelo propietario encargado del turn-taking<\/em>. Sobre esa arquitectura incorpora workflows, herramientas, testing, evaluaciones, experimentos, analytics y gesti\u00f3n de conversaciones.<\/p>\n La propuesta es reducir el n\u00famero de decisiones que un equipo necesita resolver para colocar un agente en producci\u00f3n. Eso tiene un valor econ\u00f3mico y operativo real. Cada componente que una plataforma administra es una pieza menos que el equipo interno necesita implementar, integrar, observar y mantener.<\/p>\n La contrapartida es que una mayor proporci\u00f3n 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\u00e1s sutil: configurar componentes dentro de una plataforma no equivale a ser propietario del mecanismo que los orquesta<\/strong>.<\/p>\n Esta fue una de las conclusiones m\u00e1s \u00fatiles de la investigaci\u00f3n. Pipecat cuenta con integraci\u00f3n oficial con ElevenLabs TTS. Es posible utilizar Pipecat para administrar el pipeline, transporte, contexto, herramientas y l\u00f3gica conversacional mientras ElevenLabs se ocupa \u00fanicamente de sintetizar la voz.<\/p>\n Una arquitectura podr\u00eda utilizar, por ejemplo, un STT seleccionado espec\u00edficamente por su desempe\u00f1o en espa\u00f1ol, un modelo de lenguaje diferente, herramientas conectadas con CRM o ERP y ElevenLabs para generar el audio.<\/p>\n La decisi\u00f3n deja entonces de ser \u201cPipecat o ElevenLabs\u201d y se convierte en una pregunta arquitect\u00f3nica m\u00e1s precisa: \u00bfen qu\u00e9 capas queremos utilizar ElevenLabs y en cu\u00e1les queremos conservar independencia?<\/strong><\/p>\n Vapi ocupa una posici\u00f3n intermedia. Su propuesta est\u00e1 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\u00f3n.<\/p>\n Esta estructura tiene una ventaja para equipos que quieren reducir trabajo de infraestructura sin convertir la selecci\u00f3n de modelos en una decisi\u00f3n completamente monol\u00edtica. Tambi\u00e9n muestra por qu\u00e9 el precio anunciado por minuto debe interpretarse con cuidado: la tarifa de plataforma no representa necesariamente el costo completo de la conversaci\u00f3n; representa una capa de la arquitectura.<\/p>\n Retell AI merece entrar en el an\u00e1lisis especialmente cuando el canal dominante es telefon\u00eda. Su propuesta integra infraestructura de voz, telefon\u00eda, modelos, s\u00edntesis, herramientas operativas, testing y analytics. Para casos como contact centers, reservaciones, calificaci\u00f3n telef\u00f3nica, soporte o procesos predominantemente PSTN, una plataforma de este tipo puede reducir considerablemente la cantidad de infraestructura que debe construir una empresa.<\/p>\n Una vez m\u00e1s aparece el mismo intercambio: menos ingenier\u00eda propia a cambio de aceptar una mayor dependencia de las abstracciones y econom\u00eda de la plataforma.<\/p>\n Hasta aqu\u00ed hemos hablado de arquitectura. Pero el usuario no percibe frameworks ni pipelines. Percibe una conversaci\u00f3n, y una conversaci\u00f3n se deteriora r\u00e1pidamente cuando sus tiempos dejan de parecer humanos.<\/p>\n El error habitual es hablar de \u201cla latencia\u201d del agente como si fuera una sola cifra. En un pipeline tradicional, lo que el usuario experimenta es aproximadamente la suma \u2014y, cuando existe procesamiento concurrente, la superposici\u00f3n\u2014 de varios tiempos:<\/p>\n detecci\u00f3n del final del turno + STT + razonamiento + herramientas + inicio del TTS + transporte<\/strong><\/p>\n Esto explica por qu\u00e9 seleccionar el LLM m\u00e1s r\u00e1pido no garantiza el agente m\u00e1s r\u00e1pido. Si el sistema tarda demasiado en decidir que el usuario termin\u00f3 de hablar, una parte importante del presupuesto de latencia ya se perdi\u00f3 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\u00f3n.<\/p>\n Por eso conviene tratar la latencia como un presupuesto distribuido entre componentes<\/strong>, no como un benchmark \u00fanico de plataforma.<\/p>\n 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\u00f3n suspendida antes de completarla. Un VAD puede detectar que alguien dej\u00f3 de emitir voz. Eso no significa necesariamente que haya terminado su idea.<\/p>\n Los frameworks actuales intentan resolver esta diferencia combinando se\u00f1ales ac\u00fasticas con modelos capaces de estimar si un turno est\u00e1 sem\u00e1nticamente completo. Pipecat aborda el problema mediante Smart Turn junto con VAD; LiveKit ofrece estrategias de detecci\u00f3n de turno y configuraci\u00f3n de interrupciones; ElevenAgents incorpora un modelo propietario de turn-taking.<\/p>\n La consecuencia pr\u00e1ctica es importante: comparar agentes exclusivamente por STT, LLM y TTS deja fuera uno de los componentes que m\u00e1s influye en la sensaci\u00f3n de naturalidad<\/strong>.<\/p>\n Cuando el usuario comienza a hablar mientras el agente est\u00e1 respondiendo, el sistema deber\u00eda detectar una interrupci\u00f3n leg\u00edtima y detenerse con rapidez. Pero tampoco deber\u00eda cortar su respuesta cada vez que escucha ruido, una respiraci\u00f3n o una breve se\u00f1al de asentimiento.<\/p>\n Una detecci\u00f3n demasiado agresiva puede aumentar las falsas interrupciones. Una detecci\u00f3n demasiado conservadora hace que el agente hable encima del usuario. Por ello, una prueba seria deber\u00eda medir por separado el tiempo para detectar una interrupci\u00f3n, el tiempo efectivo hasta detener el audio, la proporci\u00f3n de interrupciones leg\u00edtimas reconocidas y la tasa de falsos positivos.<\/p>\n Otro error frecuente consiste en considerar WebRTC o WebSocket como decisiones puramente de infraestructura. En aplicaciones web y m\u00f3viles, WebRTC fue dise\u00f1ado espec\u00edficamente 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\u00eda, pero utilizarlo como sustituto universal de WebRTC puede trasladar complejidad a otras partes de la aplicaci\u00f3n.<\/p>\n Para un agente que vive principalmente en navegador o m\u00f3vil, WebRTC deber\u00eda ser el punto de partida de la evaluaci\u00f3n<\/strong>. Para telefon\u00eda o comunicaci\u00f3n entre servidores, la respuesta puede ser distinta.<\/p>\n En producci\u00f3n aparecer\u00e1 inevitablemente una conversaci\u00f3n que \u201cse sinti\u00f3 lenta\u201d. Ese diagn\u00f3stico no sirve si el sistema no puede explicar d\u00f3nde se perdi\u00f3 el tiempo: reconocimiento, LLM, CRM, TTS, red o detecci\u00f3n del turno.<\/p>\n Una arquitectura de voz deber\u00eda instrumentar esas etapas desde el principio. Pipecat ofrece integraci\u00f3n con OpenTelemetry para observar diferentes componentes del pipeline. LiveKit Cloud concentra transcripciones, traces, logs y audio dentro de una l\u00ednea temporal de sesi\u00f3n. ElevenAgents incorpora analytics, testing, evaluaciones y experimentos en la propia plataforma.<\/p>\n Time to first byte<\/em> es \u00fatil para saber cu\u00e1nto tarda un componente en empezar a producir salida. Sin embargo, optimizar exclusivamente TTFB puede producir un agente t\u00e9cnicamente r\u00e1pido y operacionalmente mediocre.<\/p>\n La evaluaci\u00f3n necesita al menos tres capas. En la capa t\u00e9cnica<\/strong> interesa medir latencia end-to-end, STT, LLM TTFB, tool latency, TTS TTFB, errores, reconexiones e interrupciones. En la capa conversacional<\/strong> interesan repeticiones, solicitudes de aclaraci\u00f3n, silencios anormales, falsos cortes, abandono y transferencias. Finalmente est\u00e1 el resultado del proceso<\/strong>: si el agente existe para reservar una cita, resolver una solicitud o calificar una oportunidad, la medici\u00f3n debe llegar hasta ese resultado.<\/p>\n Existe una tentaci\u00f3n de simplificar la comparaci\u00f3n como \u201copen source significa privacidad\u201d y \u201cSaaS significa enviar los datos a terceros\u201d. La arquitectura real es m\u00e1s complicada.<\/p>\n Un deployment con Pipecat o LiveKit puede ofrecer un alto grado de control sobre infraestructura y procesamiento, pero ese control tambi\u00e9n convierte a la organizaci\u00f3n en responsable de configurar y proteger correctamente el sistema. Las plataformas administradas ofrecen diferentes mecanismos de retenci\u00f3n y privacidad. ElevenLabs, por ejemplo, documenta configuraciones de retenci\u00f3n y Zero Retention Mode, adem\u00e1s de opciones privadas para determinados clientes empresariales.<\/p>\n La pregunta \u00fatil no es \u00fanicamente d\u00f3nde corre el framework. Es por d\u00f3nde viajan los datos<\/strong>: audio \u2192 transporte \u2192 STT \u2192 modelo \u2192 herramientas \u2192 TTS \u2192 logs \u2192 analytics \u2192 almacenamiento.<\/p>\n Los precios publicados parecen ofrecer una forma sencilla de ordenar plataformas. En realidad, sus modelos comerciales son suficientemente distintos como para que la comparaci\u00f3n directa resulte enga\u00f1osa. Un framework open source no tiene una tarifa \u00fanica por conversaci\u00f3n: hay que sumar infraestructura y todos los servicios utilizados. En plataformas administradas, la tarifa base puede excluir modelos, telefon\u00eda u otros componentes.<\/p>\n Esto sugiere una ecuaci\u00f3n m\u00e1s \u00fatil:<\/p>\n TCO = infraestructura + transporte + STT + LLM + TTS + telefon\u00eda + observabilidad + ingenier\u00eda + operaci\u00f3n + soporte + costo de cambio<\/strong><\/p>\n Una plataforma administrada puede parecer m\u00e1s cara por minuto y resultar m\u00e1s econ\u00f3mica durante la etapa inicial porque elimina semanas de ingenier\u00eda. Un framework puede parecer m\u00e1s econ\u00f3mico y resultar m\u00e1s costoso si la organizaci\u00f3n construye infraestructura que nunca se convierte en una ventaja competitiva. Tambi\u00e9n puede ocurrir lo contrario a escala.<\/p>\n La pregunta econ\u00f3mica correcta no es \u201c\u00bfcu\u00e1nto cuesta un minuto?\u201d. Es \u201c\u00bfcu\u00e1nto cuesta poseer esta capacidad durante su vida \u00fatil?\u201d<\/strong><\/p>\nAntes de comparar productos, hay que entender el pipeline<\/h2>\n
Pipecat: tratar la conversaci\u00f3n como una arquitectura componible<\/h2>\n
LiveKit Agents cambia el mapa competitivo<\/h2>\n
ElevenLabs: de proveedor de voz a plataforma de agentes<\/h2>\n
Pipecat y ElevenLabs no tienen por qu\u00e9 competir<\/h2>\n
Vapi: abstraer infraestructura sin ocultar completamente los componentes<\/h2>\n
Retell: cuando el problema comienza en el tel\u00e9fono<\/h2>\n
El verdadero enemigo de la conversaci\u00f3n: la latencia acumulada<\/h2>\n
Turn-taking: donde muchos agentes dejan de parecer humanos<\/h2>\n
Las interrupciones merecen m\u00e9tricas propias<\/h2>\n
El transporte tambi\u00e9n forma parte de la experiencia<\/h2>\n
Observabilidad: saber que el agente fall\u00f3 no es suficiente<\/h2>\n
TTFB importa, pero no deber\u00eda convertirse en la m\u00e9trica dominante<\/h2>\n
Privacidad: el diagrama de datos importa m\u00e1s que la etiqueta del producto<\/h2>\n
El costo por minuto es una comparaci\u00f3n incompleta<\/h2>\n
Entonces, \u00bfqu\u00e9 opci\u00f3n conviene?<\/h2>\n