Le dices al altavoz: "Oye Mira, pon algo de dream pop."

La música empieza a sonar, con ese sintetizador que suena algo brumoso. Escuchas unos segundos y frunces el ceño: "Salta esta."

"Ya la salté por ti."

Preguntas casi sin pensarlo: "¿Qué te parece esta canción?"

"Muy suave."

Este es el agente de voz que muestra el canal oficial de Google Cloud Tech, y se llama Mira. Escucha, se la puede interrumpir, y responde casi sin retraso — como hablar por teléfono, no como hablarle a un contestador automático.

Si alguna vez construiste una aplicación de voz, seguramente sabes lo difícil que es lograr esa sensación de "hablar por teléfono". Lo que la mayoría construye la primera vez es, en realidad, un contestador automático disfrazado de voz: espera a que termines toda la frase para recitar la respuesta, y si intentas interrumpir, sigue leyendo el guion hasta el final. Uno cree que el modelo simplemente no es lo bastante inteligente, pero el problema real es que eligió la arquitectura equivocada desde el principio.

Puede que tu bot de voz siempre haya sabido "recitar", pero nunca "escuchar"

La mayoría de las IA de voz funcionan con texto a voz (TTS): le das texto y te devuelve sonido, en un solo sentido y de una sola vez. Puede hablar, pero no te escucha, ni siquiera sabe si sigues ahí.

Gemini Live API es distinto: es "audio a audio", bidireccional y en tiempo real. Recibe tu voz directamente como audio y responde también con audio. Lo que capta no son solo las palabras, sino el tono, las pausas, la emoción — todo eso que desaparece en cuanto lo conviertes en texto. Y lo más importante: va formando la respuesta mientras habla, sin esperar a que termines de pensar toda la frase para empezar a sonar. En una frase: TTS "recita", Live "escucha", y la respuesta se genera mientras se dice.

Solo hay conversación de verdad si abres una línea que no se cuelga

La arquitectura tiene tres piezas: el navegador se encarga de capturar y reproducir el audio; Gemini Live es el modelo central; y en medio hay un pequeño backend que mantiene una conexión abierta y continua con Gemini, retransmitiendo el audio tal cual. Entre el navegador y el backend se usa WebSocket — a diferencia de una petición web normal que se cierra apenas recibe respuesta, esta línea permanece abierta, y solo así el audio puede fluir en ambos sentidos de forma continua.

El backend hace dos cosas a la vez: envía hacia arriba el audio del micrófono y recibe hacia abajo la voz de Gemini, y ninguna de las dos espera a la otra — ocurren en paralelo. Por eso esta "llamada" se siente siempre viva. El ciclo central son solo cuatro pasos: abrir la conexión, enviar audio, recibir audio, reproducir. Llegado a este punto ya tienes un agente que "funciona" — pero que funcione y que sea una conversación de verdad son cosas distintas.

Que pueda conversar no basta: primero tiene que aprender a saber cuándo terminaste de hablar

Para que se sienta viva todavía faltan tres cosas. La primera: ¿cómo sabe el modelo que terminaste de hablar? La respuesta es la detección de actividad de voz (VAD) — el modelo se pregunta constantemente: ¿hay alguien hablando ahora, o hay silencio? Con eso encuentra el inicio y el final de tu turno, y por eso hay que seguir transmitiendo el flujo de audio incluso cuando estás en silencio. La buena noticia es que Gemini Live ya trae VAD integrado, así que no hace falta escribir esa lógica de detección desde cero.

Lo que realmente te convence de que "esto está vivo" es el instante en que la interrumpes

Lo segundo es si se puede "interrumpir" (barge-in). Un walkie-talkie no lo permite, pero una conversación real sí — hablas a mitad de una frase y te impones, y el otro se detiene. El mismo VAD también detecta si empiezas a hablar mientras el modelo está hablando; en cuanto lo detecta, el modelo se detiene por sí mismo y envía una señal de interrupción.

Lo que de verdad hace que la interrupción se sienta instantánea es un detalle fácil de pasar por alto: la aplicación debería detener la reproducción local en cuanto el micrófono capta que empezaste a hablar, sin esperar a que la señal complete todo el viaje de ida y vuelta por la red. Primero detener la reproducción, y que el modelo se ponga al día después — hacer bien este paso es lo que hace que interrumpir se sienta como una conversación real, y no como un robot con retraso.

Solo saber hablar no es suficiente: hay que darle un par de manos

Lo tercero es la capacidad de actuar. El modelo, por sí solo, solo puede "hablar" — no puede reproducir una canción, saltarla ni pulsar un botón. Por eso hay que darle tools (herramientas): una tool es una función en el código, con un nombre y una descripción, que representa una acción concreta que el modelo puede pedirte que hagas, como reproducir una lista, saltar la canción actual o pausar la música.

Cuando el modelo determina que necesita usar una tool, no se inventa una respuesta para salir del paso: dice "llama a esta tool con estos parámetros", tu programa la ejecuta y reporta el resultado, y el modelo continúa a partir de ahí — el modelo decide, el código actúa. Aquí hay una regla especialmente importante para la voz: mientras la tool se ejecuta, el modelo se queda esperando en su sitio, así que la tool tiene que correr rápido; si tarda demasiado, toda la conversación cae en un silencio.

Que funcione no significa que ya sepas cuánto te va a costar esta "llamada"

Con las tres piezas juntas — VAD encuentra los límites de tu turno, barge-in te deja interrumpir en cualquier momento, y las tools le permiten actuar de verdad — todo el agente ya funciona, y la sensación es realmente la de hablar por teléfono.

Pero pocos tutoriales te lo advierten: una conexión de voz bidireccional que "se abre y se queda abierta" no sigue la misma lógica de consumo que una petición de texto de pregunta y respuesta. Cuando un chat de texto está en silencio, no pasa nada; una conexión que se mantiene transmitiendo de forma continua para poder ser interrumpida en cualquier momento funciona de manera completamente distinta. No es un problema que la demostración busque resolver, pero sí es la factura que tarde o temprano vas a tener que abrir antes de llevar esto a un producto real — y calcularlo después de que los usuarios ya se acostumbraron a "poder interrumpir en cualquier momento" suele doler mucho más que haberlo puesto en la lista de evaluación desde el principio.

De "poder conversar" a "sentirse como una llamada"

Volvamos a esa frase del principio: "Oye Mira, pon algo de dream pop." Lo que hace posible esa escena no es lo inteligente que hable el modelo, sino los detalles que casi ni notas: que siempre está escuchando, que si la interrumpes de verdad se detiene, y que de verdad puede mover el dedo y cambiar la canción. Desde el momento en que empiezas a construir tu propio agente de voz, no solo tienes que vigilar si "sabe hablar", sino también si entiende el instante en que lo interrumpes, y en qué factura terminará convirtiéndose esa línea que se queda abierta todo el tiempo. Si metes estas dos cosas en el diseño desde la primera versión, lo que construyas no será solo un contestador automático que sabe hablar.

Preguntas frecuentes (FAQ)

Q1: ¿En qué se diferencia Gemini Live API del texto a voz (TTS) tradicional? TTS es unidireccional: le das texto y produce sonido, sin escucharte ni saber si sigues ahí. Gemini Live es bidireccional y en tiempo real, audio a audio, capaz de captar el tono y las pausas, y va generando la respuesta mientras habla.

Q2: ¿Cómo se logra la interrupción de voz (barge-in)? Se apoya en la detección de actividad de voz (VAD), que determina tanto si ya terminaste tu turno como si estás hablando mientras el modelo lo hace. Al detectar la interrupción, el modelo se detiene por sí mismo y envía una señal de corte; del lado de la aplicación, lo ideal es detener la reproducción local en cuanto el micrófono capta que empezaste a hablar, para que la interrupción se sienta instantánea.

Q3: ¿Hay que programar el VAD desde cero? No. Gemini Live ya trae integrada la detección de actividad de voz, así que no hace falta construir tu propio mecanismo para determinar si alguien está hablando o no.

Q4: ¿Por qué el tool calling tiene que ser rápido en un agente de voz? Mientras la tool se ejecuta, el modelo se queda esperando en su lugar; si tarda demasiado, la conversación cae en silencio. La voz exige una respuesta inmediata mucho más que un chat de texto, así que las tools deben diseñarse para devolver resultados lo antes posible.

Fuente: este artículo es una reelaboración basada en el video del canal oficial de Google Cloud Tech, "Build a real-time voice AI agent with Gemini Live API" (publicado el 2026-08-26, con aproximadamente 121.000 visualizaciones), enlace original: https://www.youtube.com/watch?v=pFc-HcUgFgY. Las capacidades descritas de Gemini Live API se basan en la demostración del video original; para las funciones reales y las tarifas, consulta la documentación oficial de Google Cloud. Este artículo no constituye una garantía de implementación técnica.

Para seguir leyendo: qué es OpenAI Codex y en qué se diferencia de ChatGPT, por qué los AI Token son tan caros, qué es Claude Fable 5, y por qué el software está pasando a cobrarse por token.

Cuando construyas tu propio agente de voz, esa conexión que se abre y se queda abierta terminará convirtiéndose en una factura: ¿prefieres verla con claridad desde ahora, o esperar a que llegue para revisarla? Prueba gratis AI Token King: https://aitokenking.com.tw/home