Una pausa de dos segundos parece pequeña en una métrica y enorme en una llamada. El usuario piensa que se ha cortado, vuelve a hablar y el agente responde a una frase que ya no existe. Ahí se descubre que un agente de voz no es un chatbot con micrófono.
La dificultad está en mantener una conversación viva mientras se escucha, se razona, se consultan sistemas y se reproduce audio. Todo a la vez, con interrupciones y sin perder el estado de la gestión.
Dos formas de construir la conversación
En una arquitectura nativa de voz a voz, el modelo recibe audio y genera audio dentro de una sesión persistente. Conserva matices prosódicos y empieza a responder sin esperar a que exista una transcripción completa. Es la opción más natural para diálogo fluido.
La arquitectura en cascada convierte primero la voz en texto, pasa ese texto por un agente y sintetiza la respuesta. Añade pasos y latencia, pero deja artefactos intermedios fáciles de inspeccionar. También permite elegir un transcriptor, un modelo y una voz distintos.
| Criterio | Voz a voz en tiempo real | STT → agente → TTS |
|---|---|---|
| Sensación conversacional | Más fluida y expresiva | Más dependiente de las pausas entre etapas |
| Control del texto | La transcripción puede ser secundaria | El texto es el contrato entre componentes |
| Depuración | Exige observar eventos, audio y herramientas | Permite aislar cada etapa con facilidad |
| Sustitución de piezas | Más ligada al proveedor de la sesión | Componentes intercambiables |
| Mejor encaje | Conversación abierta y baja latencia | Procesos pautados, trazabilidad textual y voces específicas |
La elección no tiene por qué ser definitiva. Un servicio puede usar voz nativa durante la conversación y exigir una confirmación textual estructurada antes de ejecutar una operación sensible.
La arquitectura real está alrededor del modelo
WebRTC suele encajar en navegador; WebSocket, en conexiones de servidor; SIP permite integrar telefonía. La sesión recibe eventos de audio, transcripciones, llamadas a herramientas y cambios de estado. Los SDK actuales también contemplan conexión SIP y seguimiento de la reproducción para saber qué parte de una respuesta llegó a oír realmente el interlocutor (OpenAI, OpenAI).
Ese último dato evita un error frecuente. Si el agente dice “su cita es el martes a las…” y el usuario interrumpe antes de la hora, la memoria no debería registrar que la cita completa fue comunicada.
La latencia no es un número único
“Responder en menos de un segundo” sirve como objetivo, pero ayuda poco a localizar el problema. Hay que repartir el tiempo:
- El audio viaja y se almacena en pequeños fragmentos.
- El sistema decide que el usuario ha terminado, o que puede empezar a responder.
- El modelo interpreta el turno y decide si necesita una herramienta.
- El CRM, la agenda o el sistema de pedidos responde.
- Se genera audio suficiente para comenzar la reproducción.
Una consulta lenta al ERP puede dominar toda la experiencia. En ese caso, acelerar el modelo apenas se nota. Es preferible que el agente confirme brevemente lo que está haciendo y continúe cuando llegue el dato, siempre que esa frase no finja que la operación ya terminó.
La detección de fin de turno también exige ajuste. Un umbral agresivo corta a quien habla despacio; uno conservador deja silencios incómodos. Conviene probar con acentos, ruido, dudas, frases incompletas y personas que piensan mientras hablan.
Interrumpir bien es parte del diálogo
La interrupción —o barge-in— no consiste solo en silenciar el altavoz. El sistema tiene que detener la reproducción, marcar hasta dónde escuchó el usuario, incorporar el nuevo audio y decidir qué parte de la respuesta anterior sigue siendo válida.
En una llamada de soporte, “no, ese no es mi pedido” invalida el contexto que estaba usando el agente. En otra, “un momento” solo pide una pausa. Resolver ambas con la misma regla produce conversaciones torpes.
Cinco pruebas que revelan si la conversación aguanta
- Interrupción temprana. El usuario corta la primera frase y cambia de intención.
- Solapamiento. Habla mientras el agente termina una cifra o una fecha.
- Silencio largo. Busca un dato sin que la llamada se cierre ni el agente le presione.
- Corrección tardía. Rectifica un nombre después de haber avanzado varios turnos.
- Transferencia. Pide una persona y el contexto llega completo al operador.
Grabar solamente la transcripción no permite revisar estos casos. Hace falta conservar la secuencia de eventos, tiempos de inicio y fin, audio reproducido, cancelaciones y herramientas ejecutadas.
Identidad, memoria y herramientas: tres riesgos unidos
La voz transmite familiaridad, pero no demuestra identidad. Reconocer un número entrante o que alguien conozca un dato no basta para autorizar un cambio de cuenta. La autenticación debe ajustarse al riesgo de la operación y mantenerse separada de la impresión conversacional.
La memoria de la llamada necesita distinguir hechos confirmados, hipótesis y datos caducados. “Creo que fue el pedido 1842” no puede convertirse silenciosamente en el pedido verificado. Si la sesión continúa otro día, solo debería persistir lo necesario y permitido.
Las herramientas elevan el valor y el riesgo. Consultar disponibilidad es reversible; cancelar una póliza no. Los frameworks de agentes en tiempo real permiten ejecutar herramientas, aplicar guardrails y requerir aprobaciones, pero el diseño de esos puntos sigue siendo responsabilidad del proceso (OpenAI).
Ejemplo: reprogramar una cita sin crear dos
Una paciente llama para mover una cita. El agente identifica el motivo, verifica su identidad con el mecanismo acordado y consulta huecos. Mientras enumera la segunda opción, la paciente interrumpe: “la primera me sirve”.
El sistema debe saber que la primera opción sí fue escuchada, confirmar fecha y centro, y reservar mediante una operación idempotente. Si la herramienta tarda, no repite la reserva. Antes de cerrar, lee el resultado devuelto por la agenda, no el horario que había propuesto unos segundos antes.
Si identidad, disponibilidad o confirmación quedan ambiguas, transfiere la llamada junto con el resumen y los datos ya verificados. La persona no debería empezar de cero.
Evaluar llamadas, no respuestas aisladas
Una prueba de texto puede detectar errores de política, pero no mide el sistema completo. El conjunto de evaluación debería incluir llamadas reales anonimizadas o escenarios representativos con ruido, interrupciones, acentos, nombres propios y fallos de herramientas.
Las métricas útiles combinan varias capas: tiempo hasta la primera respuesta, silencios improductivos, precisión de entidades, éxito de herramientas, correcciones, transferencias, cumplimiento de avisos y resolución de la gestión. También interesa cuánto esfuerzo necesita la persona después de la llamada.
Una tasa alta de contención puede ser mala señal si impide escalar. En voz, retener a alguien dentro de una conversación que no progresa resulta especialmente frustrante.
Preguntas frecuentes
¿Un agente de voz debe avisar de que es IA?
Conviene hacerlo con claridad y puede ser obligatorio según la jurisdicción y el contexto. El aviso debe formar parte del guion y quedar registrado, no ocultarse en una locución acelerada.
¿Se necesita guardar el audio completo?
No siempre. Depende de la finalidad, el consentimiento y las obligaciones aplicables. Se pueden conservar eventos, resultados o fragmentos justificados, con plazos y accesos definidos.
¿Qué ocurre si falla una herramienta durante la llamada?
El agente debe reconocer que la operación no se completó, evitar reintentos peligrosos y ofrecer una alternativa: volver a intentar de forma controlada, crear una tarea o transferir.
¿Puede cambiarse la voz durante una sesión?
Depende de la plataforma. En las sesiones Realtime actuales de OpenAI, la voz no puede cambiar después de que la sesión haya emitido audio (OpenAI). Conviene fijarla antes de comenzar.
¿Cuándo es mejor un menú telefónico tradicional?
Cuando hay pocas opciones estables, la entrada es inequívoca y el coste del error es alto. La conversación libre aporta valor cuando el usuario expresa motivos variables o necesita combinar consulta y gestión.
Diseñar primero la llamada difícil
Una demo limpia suele tener buena cobertura, turnos ordenados y una API rápida. Producción trae ruido, dudas, interrupciones y sistemas que responden tarde.
El diseño debería comenzar por esa llamada incómoda: la persona que corrige tres veces un dato, la herramienta que falla después de una confirmación y la transferencia que debe conservar el contexto. Si el agente resuelve bien esos bordes, la voz empieza a parecer un canal operativo. Si no, solo habla.
Fuentes consultadas
- Realtime agents guide — OpenAI Agents SDK
- Realtime transport — OpenAI Agents SDK
- Realtime configuration — OpenAI Agents SDK
- Voice pipeline — OpenAI Agents SDK
Fuentes y vigencia técnica revisadas el 18 de agosto de 2026.