Agentes de voz: la voz es lo que menos importa

Todo el mundo que habla de "agentes de voz" habla de la voz: qué tan natural suena, qué tan rápido responde, si te deja interrumpirlo. Nosotros elegimos bien la pieza de voz — Deepgram Voice Agent, que hace transcripción, detección de turno y síntesis en un solo servicio — y esa parte se resolvió casi sola. Lo que estuvo a punto de tirar el proyecto no tuvo nada que ver con hablar ni con escuchar.

El moderador de Quorum se había quedado mudo. Mi equipo llevaba horas optimizando: menos contexto, modelo más rápido, memoria más liviana. Cada arreglo se sentía correcto. El moderador seguía sin contestar.

Les dije que no podía ser velocidad — el mismo POC ya funcionaba con el mismo modelo, tenían que estar viendo mal el problema. Tenía razón, pero no por donde yo pensaba: el problema no era velocidad, ni el modelo, ni nada que sonara a "voz". Era que Deepgram esperaba la respuesta en streaming, formato SSE, y le estábamos devolviendo un JSON plano. No importaba qué tan rápido respondiera — el formato ya estaba mal desde el principio. Un bug de plomería, no de oído.

Ese es el patrón de todo el proyecto: cada vez que algo casi se rompe, no fue la voz. Fue todo lo que hay detrás de ella.

De dónde salió esto

Quorum ya deliberaba por texto — CFO, CISO, CTO, Strategist discutiendo con quien escribiera en la sala. Pero "escribir" no es "discutir". El salto real era dejar que alguien hablara con el panel y que el panel respondiera de vuelta, en segundos, sin botones de por medio.

La pieza que lo hizo posible no nació para Quorum. Nació en mi proyecto de voz de oficina — un agente de llamadas salientes. Antes de tocar Quorum, tuvimos que resolver la voz ahí primero. Y resolverla resultó ser la parte fácil.

El arranque: LiveKit, y bugs que tampoco eran de voz

La primera versión fue LiveKit self-hosted: STT de Deepgram, LLM directo (Gemma, MiniMax, DeepSeek — sin enrutador automático, porque ya habíamos medido que el "auto" variaba muchísimo de un turno a otro), TTS Aura-2.

Ninguno de los bugs de esta etapa fue "la IA no entiende lo que le digo". Todos fueron infraestructura disfrazada de mal comportamiento:

• El detector de turnos se quedaba colgado y el modelo simplemente dejaba de contestar. Sin error visible — nada que buscar en un log.
• "A veces funciona, a veces no" resultó ser LiveKit despachando el agente una sola vez por sala creada, no en cada reconexión. Pura suerte de si la sala vieja seguía viva.
• Mi celular se quedaba en "conectando" para siempre, porque le estábamos dando la IP cruda de la red interna en vez de una URL pública.

Cada uno se ve obvio ya explicado. Ninguno lo era mientras pasaba, y ninguno tenía que ver con qué tan bien "hablaba" el agente.

El giro: comparar de frente, en vez de seguir parchando

En algún punto, en vez de seguir arreglando LiveKit a mano, armamos una comparación directa de tres arquitecturas completas sobre el mismo problema:

• A — LiveKit puro, el stack original, self-hosted.
• B — Deepgram Voice Agent API sola, todo en un solo websocket: STT, detección de turno y TTS en la nube de Deepgram.
• C — B más VAD del lado del cliente, para que si el usuario interrumpía, el audio del agente se cortara al instante.

El Voice Agent le ganó por mucho — no porque "sonara mejor", sino porque Deepgram ya tiene resuelto, como producto, un modelo semántico de cuándo termina una idea en vez de solo medir silencio (que es todo lo que hacía LiveKit). Lo probé yo mismo en vivo, las tres seguidas. La parte de voz en sí —la que todo el mundo asume que es lo difícil— vino resuelta de fábrica en cuanto elegimos la herramienta correcta. No tuvimos que construirla.

De regalo, comparando arquitecturas salió un hallazgo que no estábamos buscando: un modelo local de razonamiento (qwen3) simplemente no sirve para voz. No hay forma de apagarle el pensamiento con el tipo de endpoint que estas herramientas esperan — se queda pensando en voz baja mientras uno espera una respuesta. Ni siquiera esto es un problema "de voz": es un modelo pensado para otra cosa, mal encajado.

La apuesta grande: conectarlo a Quorum

Hasta aquí, todo era "un LLM contesta lo que le llega". Meterlo a Quorum cambió la naturaleza del problema — y otra vez, el cambio no fue de voz. Fue de memoria y de estado: el moderador necesitaba memoria real de la empresa, la conversación tenía que quedar grabada en la sala, y tenía que poder proponer hechos nuevos igual que lo hace por texto.

Eso significó que Deepgram ya no le habla directo a un modelo — le habla a Quorum, y Quorum es quien le habla al modelo (DeepSeek v4-flash). Un salto de red extra. Invisible hasta que dejó de funcionar — que es exactamente cuando llegó el bug del streaming con el que arranca este post.

Lo que solo se ve con datos reales

Resuelto el formato, todavía quedaban capas que ningún curl simulado había tocado — y otra vez, ninguna era "de voz":

La búsqueda de memoria le fallaba a preguntas en español. Casi toda nuestra memoria de empresa está en inglés, y el embedding no cruza idiomas tan bien como uno asume — el mismo hecho, medido en las dos versiones, salía en la posición 1 en inglés y en la posición 13 en español. Esto pasaría igual si Quorum funcionara solo por texto.

La única que sí toca la voz directamente: leyendo la transcripción completa de una sesión real, no un smoke test, encontramos que el moderador me había interrumpido doce veces seguidas mientras yo terminaba una sola frase. El modelo de audio por default no reconoce las pausas naturales de alguien pensando en voz alta — las lee como "ya terminé de hablar". El arreglo fue cambiar a otro modelo (Flux), que sí distingue eso. Y aun así, el arreglo fue "elegir mejor la pieza de voz", no construir una propia.

En producción, un turno completo — yo hablo, el moderador responde — tarda entre 1 y 7 segundos, la mayoría bajo 5.

Lo que me llevo

La voz resultó ser la parte más fácil de comprar bien: elegir el proveedor correcto (Deepgram Voice Agent sobre LiveKit) resolvió turno, interrupción y naturalidad casi de un jalón. Todo lo que de verdad costó trabajo estaba un nivel abajo, donde nadie mira cuando piensa en "agentes de voz": el protocolo exacto que espera el proveedor, la memoria que hay detrás, el idioma en que está escrita esa memoria. Un agente de voz no es un problema de audio con un LLM pegado. Es un sistema completo — memoria, protocolo, estado — al que además le agregaste un micrófono.

Lo que falta

No tenemos un roadmap formal para la voz en Quorum más allá de lo que ya está en producción — es de hace apenas un par de días. Lo que sí sigue abierto del proyecto original:

• Re-medir latencia con MiniMax de forma directa, sin capas intermedias.
• Comparar los tres proveedores de voz en igualdad de condiciones, no solo por impresión en vivo.
• Probar una interrupción real, no simulada — que alguien me corte a media frase de verdad y ver qué tan bien lo absorbe.
• Un hueco que no es técnico: para el flujo original de llamadas salientes no tenemos todavía un documento de cumplimiento sobre horarios y lista de no molestar. Hoy ese límite lo pone el sentido común del prompt, no una base legal verificada.