Cómo crear un agente de voz con IA (Guía completa)

Aquí está la verdad que nadie les cuenta a los que construyen agentes de IA. Los agentes de voz no necesitan

el mejor modelo. Todo lo que necesitan es:

TLDR; si leer te aburre o tu capacidad de atención está destruida, puedes usar el archivo de skill que hice para obtener el artículo completo y pegarlo en tu agente ➡️https://github.com/codejunkie99/voice-agent-builder

Todo lo que necesitas para construir es:

• un pipeline en tiempo real con un presupuesto de latencia real
• cinco componentes conectados en el orden correcto
• un anclaje lo suficientemente fuerte para mantener honesto al modelo
• un bucle de revisión semanal que se acumule

OpenAI lanzó GPT-Realtime-2 el 7 de mayo de 2026. Salesforce AI Research publicó el artículo VoiceAgentRAG el 1 de marzo, la misma semana en que Deepgram Flux pasó de beta a disponibilidad general. Las piezas dejaron de ser el problema.

Lo que siguió siendo el problema es cómo las conectas y qué escribes para que diga el agente.

Pasé los últimos tres meses construyendo agentes de voz que realmente contestan el teléfono. No voy a fingir que todo fue limpio.

• La primera versión sonaba como un quiosco. La deseché en dos días.
• La segunda versión "reservó" cuatro citas fantasma en la primera hora antes de que me diera cuenta.
• La tercera versión tuvo una fuga de memoria porque olvidé invalidar el caché de contexto después de que el extractor de fondo escribiera nuevos datos.
• Para cuando algo funcionó, el sistema era la cuarta reescritura.

La versión que defendería ahora tiene un conjunto pequeño de propiedades que explicaré durante las próximas 6,000 palabras.

• El pipeline tiene un trabajo dentro de un presupuesto. Cinco componentes, menos de 700 ms de extremo a extremo, sin excepciones.
• El conocimiento vive en tus documentos y se recupera con un caché de doble agente, no se extrae de la cabeza del modelo.
• El diseño de conversación es la disciplina de escribir para oídos, no para ojos. La mayoría de los equipos lo tratan como algo cosmético. No lo es.
• Cada turno escribe un registro estructurado que puedo reproducir contra la configuración actual 90 días después.

Este artículo es lo que realmente me enseñaron esos 90 días, más las dos o tres apuestas que haría primero si empezara de nuevo hoy.🔽🔽

Lo que realmente es un agente de voz

Un agente de voz no es un chatbot con un micrófono añadido. No es un envoltorio de TTS alrededor de una API de texto.

Es un sistema de audio en tiempo real. Con restricciones de latencia. Cinco componentes coordinándose dentro de una ventana de 300 a 800 milisegundos.

El pipeline en el orden en que realmente ocurren los eventos:

1. El usuario habla
2. El audio se captura
3. El STT en streaming transcribe palabra por palabra, mientras la persona aún está hablando
4. El agente lee la transcripción y recupera el conocimiento relevante de tus documentos
5. El LLM genera una respuesta
6. El TTS pronuncia la respuesta en voz alta
7. El usuario la escucha

Cada una de esas flechas es un componente que puedes elegir, ajustar y reemplazar.

Primero intenté construirlo a la manera de un chatbot. El STT completa, envía al LLM, espera la respuesta completa, envía al TTS, espera el audio completo, reproduce.

Se sintió horrible. Como hablar con un quiosco. En dos días lo eliminé.

La razón por la que se sintió horrible no es que los números de latencia fueran malos. En papel estaban bien. La razón es que los humanos no conversan por turnos. Conversan en flujos superpuestos.

• El agente tiene que empezar a formular una respuesta mientras el usuario aún está terminando la oración.
• El TTS tiene que empezar a hablar antes de que el LLM termine de escribir.
• El STT tiene que seguir escuchando mientras el agente habla, para saber cuándo callarse.

Un agente de voz que no puede ser interrumpido no es un agente de voz. Es un buzón de voz.

Las tres arquitecturas

Solo hay tres. Elige según lo que necesites controlar.

Pipeline encadenado

• Servicios separados de STT, LLM y TTS conectados entre sí
• Tres modelos independientes, cada uno especializado en su tarea
• El texto fluye entre ellos
• La latencia se sitúa entre 600 y 700 ms en una plataforma gestionada bien ajustada
• El más controlable, más depurable, más fácil de actualizar una capa a la vez

Semicascada

• El audio va directamente a un modelo multimodal que escucha el audio, no la transcripción
• Capta la frustración en la voz de alguien, una pregunta implícita por el tono ascendente, un cambio de idioma en medio de una frase
• La salida aún se enruta a través de un TTS especializado para el control de audio
• La latencia baja a 300-500 ms

Voz a voz nativa

• Un solo modelo, audio de entrada, audio de salida
• Sin capa de transcripción, sin transferencias de texto
• Todos los laboratorios importantes lanzaron un modelo de voz nativo en 2026
• La latencia baja a 200-300 ms, por debajo del umbral donde los que llaman dejan de notar que hablan con una IA

Por dónde empezar

1. Empieza con el pipeline encadenado. Las mejores herramientas existen para él. Pásate a voz a voz una vez que hayas probado tu producto en el pipeline y quieras una mejora escalonada de latencia.
2. Intenté usar voz a voz primero para todo. Fue excelente para flujos de reserva.
3. Se desmoronó en un formulario de admisión de 12 pasos porque el modelo único no podía mantener la máquina de estados en su cabeza sin que el contexto se inflara para el turno nueve.
4. Moví ese caso a un pipeline encadenado con una capa real de máquina de estados y la tasa de finalización saltó del 61% al 89% en tres días.
5. El alcance de las herramientas por estado fue toda la solución.

Los cinco componentes que debes conectar

Cada pipeline encadenado tiene los mismos cinco componentes. Cinco tareas que deben completarse antes de que tu agente atienda su primera llamada.

Los oídos (STT en streaming)

El modelo STT convierte el audio entrante en texto en tiempo real, palabra por palabra, mientras la persona aún está hablando. Este es el componente más importante de tu pila. Un error de transcripción aquí se propaga a todo lo demás.

Qué buscar en 2026:

• Precisión en streaming. Preciso mientras la persona habla, no solo después de que termine.
• Tasa de error de palabras. Del 6 al 8% en audio de producción real es bueno. Más del 12% frustrará a los usuarios en una de cada tres llamadas.
• Detección de fin de turno integrada. La mejora de UX más grande de 2026.

Por qué importa la detección de fin de turno:

• El STT genérico devuelve transcripciones. No te dice cuándo el hablante ha terminado.
• Sin ello, tu agente interrumpe a mitad de frase o espera dos segundos incómodos.
• La ola de modelos STT en streaming de 2026 incluye detección de fin de turno dentro de la misma red que produce la transcripción.
• El modelo emite una señal de turno completado cuando decide que el hablante ha terminado.
• La señal usa contexto semántico, no solo silencio acústico. Capta titubeos e ignora pausas de respiración.
• Cambia a esto si tu proveedor lo ha lanzado. La pausa antes de que el agente comience a hablar se reduce de 200 a 400 ms en cada turno.

El cerebro (LLM)

El LLM lee la transcripción, el historial de la conversación, el conocimiento recuperado y decide qué decir. También decide acciones, no solo palabras.

Reglas específicas para voz:

• Usa el modelo pequeño y rápido, no el insignia. Los modelos de razonamiento de frontera tardan 1500 ms en generar la primera palabra. Eso es silencio muerto. Los modelos más pequeños de la misma familia casi siempre ganan en turnos de voz.
• Escala al modelo grande solo para llamadas a herramientas complejas específicas que necesiten planificación real.
• Limita el prompt del sistema a 800 tokens. Se recarga en cada turno. Un prompt de 4000 tokens añade latencia a cada mensaje.

Llamadas a funciones, en lenguaje sencillo:

• Defines cada función con una descripción de lo que hace y qué información necesita.
• El LLM lee la descripción y decide cuándo llamarla según el estado de la conversación.
• Sin árbol de lógica condicional. El LLM empareja la intención con la función a partir del lenguaje natural.

El fallo de producción más común con las llamadas a funciones no es lo que esperarías:

• El LLM no lanza un error cuando no puede llamar a una función. Narra la acción en su lugar.
• "He confirmado tu reserva". No se llamó a nada. El usuario piensa que está reservado. No lo está.
• La solución es limitar las herramientas al estado actual. Un estado de "recoger nombre" no debe exponer book_appointment. Un estado de "confirmar detalles" no debe exponer check_availability.
• La máquina de estados es la barandilla de seguridad, no el prompt del sistema.

El conocimiento (RAG)

RAG es el mecanismo que permite a tu agente responder desde tus documentos en lugar de los datos de entrenamiento del modelo.

Por qué no puedes saltarte esto:

• Los LLM se entrenan en internet público hasta una fecha límite.
• Saben mucho sobre el mundo. No saben nada específico sobre tus productos, precios, políticas o clientes.
• Sin RAG, un agente al que le pregunten "¿qué incluye el plan empresarial?" alucinará con confianza.
• Con RAG, recupera la respuesta real de tu documentación antes de responder.

El mecanismo básico:

• El usuario hace una pregunta.
• El sistema incrusta la consulta.
• La base de datos vectorial devuelve los fragmentos de documentos más relevantes.
• Los fragmentos se inyectan en el contexto del LLM.
• Se le indica al LLM que responda solo a partir de ese contexto.

El desafío específico de la voz:

• Una consulta típica a una base de datos vectorial añade de 50 a 300 ms al pipeline.
• Combinado con STT, LLM y TTS, eso supera tu presupuesto de latencia.
• La solución es el patrón de caché de doble agente. Sección completa sobre esto más abajo.

La boca (TTS)

El TTS convierte texto en audio hablado. Suena simple. En realidad es un factor de diferenciación importante en la calidad percibida.

Lo que importa:

• Tiempo hasta el primer audio. Un TTS que tarda 200 ms en empezar a hablar consume un tercio de tu presupuesto de latencia solo en la capa de salida.
• Calidad de voz. Los humanos somos extraordinariamente sensibles al habla sintética. Artefactos sutiles, ritmo poco natural, acentos mal colocados: todo se interpreta como un veredicto sobre todo el sistema.
• Elige la voz intencionalmente. Es una señal de confianza antes de que el usuario haya escuchado una oración.

Las manos (Funciones e integraciones)

Las funciones son acciones que el LLM puede realizar durante la conversación:

• Reservar citas
• Consultar estados de pedidos
• Enviar SMS de confirmación
• Transferir a un humano
• Actualizar registros en tu CRM

Este es el cambio arquitectónico que hace que los agentes de voz modernos sean mucho más capaces que los sistemas de "presione 1 para facturación".

El presupuesto de latencia en el que debes encajar

Lo más importante y no obvio sobre los agentes de voz: cada milisegundo de tiempo de procesamiento es un milisegundo de silencio en el que se sienta el que llama.

Las matemáticas:

• Los humanos esperan una respuesta conversacional dentro de 500 a 700 ms después de terminar una oración
• Más de un segundo se siente como si el sistema estuviera batallando
• Más de dos segundos, los que llaman empiezan a hablar por encima del agente

Esos 700 ms son todo tu presupuesto, dividido entre cada componente.

Presupuesto por componente, carril rápido vs carril lento:

• Transporte. 20-50 ms punto a punto. 50-100 ms a través de repetidores.
• Primer intermedio de STT. 100-150 ms en acierto de caché. 150-250 ms en fallo.
• Detección de fin de turno. Integrada en el modelo, ~50 ms. Por umbral de silencio, 300-600 ms.
• Recuperación RAG. Menos de 1 ms en acierto de caché. 80-150 ms en BM25 local + reordenamiento.
• Tiempo hasta el primer token del LLM. 150-250 ms con un modelo pequeño. 400-600 ms con un modelo de frontera.
• Tiempo hasta el primer audio del TTS. 60-100 ms en el nivel rápido. 150-250 ms en el nivel de calidad.
• Sobrecarga de red. 40-80 ms en total dentro de una región. 100-160 ms en total entre regiones.
• De extremo a extremo. ~440 ms en el carril rápido. ~700-900 ms en el carril lento.

Las dos mayores ventajas en 2026:

1. Detección de fin de turno integrada en el modelo. Elimina de 200 a 400 ms de cada turno. La mejora más grande que puedes hacer este año.
2. Preobtención especulativa con un caché de doble agente. Lleva la recuperación de "fallo con búsqueda vectorial" a "acierto con búsqueda en caché" en aproximadamente el 40% de los turnos.

Todo lo demás son errores de redondeo comparado con esos dos.

El patrón RAG de doble agente

El RAG estándar dentro de un bucle de voz es un problema. La consulta a la base de datos vectorial toma de 80 a 300 ms y supera tu presupuesto de latencia en cada turno.

La respuesta de la investigación de 2026 proviene del artículo VoiceAgentRAG de Salesforce AI Research, publicado en marzo. La idea es simple.

• En una conversación real, la siguiente pregunta suele ser predecible a partir de la actual.
• Alguien que pregunta sobre precios probablemente preguntará después sobre el nivel empresarial.
• Alguien que pregunta sobre instalación probablemente preguntará después sobre compatibilidad.

Así que ejecutas dos agentes al mismo tiempo.

El agente de fondo (Pensador lento)

• Se ejecuta mientras el usuario escucha la respuesta actual
• Predice las tres a cinco preguntas de seguimiento más probables usando el LLM
• Preobtiene fragmentos de documentos relevantes para cada predicción
• Los almacena en un caché local en memoria antes de que el usuario termine de escuchar la respuesta actual

El agente en primer plano (Hablador rápido)

• Maneja la siguiente pregunta en vivo verificando primero el caché en memoria
• Una búsqueda en caché toma menos de 1 ms frente a 110 ms de una llamada remota a la base de datos vectorial
• Si el caché tiene la respuesta, omite la base de datos por completo
• Si el caché falla, recurre a la base de datos y guarda ese resultado en caché para la próxima vez

Números de referencia del artículo

• El 75% de las consultas aciertan en el caché
• Aceleración de 316× en la recuperación en aciertos de caché (0.35 ms vs 110 ms)
• 16 segundos de latencia acumulada ahorrados en 200 consultas

El principio a recordar: usa el tiempo de escucha del usuario como tu tiempo de cómputo. El momento en que empiezan a escuchar la respuesta actual es el momento en que empiezas a prepararte para su siguiente pregunta.

Probé el RAG vectorial simple dentro del bucle de voz en mi primera versión. Añadió 110 ms por turno.

Mató la sensación de conversación. Cambié al patrón de caché de doble agente en la semana seis. El 40% de los turnos que aciertan en el caché se sienten más rápidos que los agentes humanos del centro de llamadas a los que reemplaza.

El diseño de conversación es la disciplina que la mayoría de los constructores omiten

Puedes tener el STT más rápido, el LLM más pequeño, el caché RAG más inteligente. Si tu agente no sabe hablar, los que llaman colgarán.

El diseño de conversación es la disciplina de escribir para oídos, no para ojos.

Reglas que sigo ahora que aprendí al equivocarme primero

• Habla en oraciones cortas. La capacidad de atención humana promedio para información hablada es de 8 a 10 segundos. Una respuesta de 15 segundos es demasiado larga. Divídela en dos turnos.
• Nunca hagas dos preguntas en un solo turno. Los que llaman solo pueden retener una en la memoria de trabajo. Pregunta una, espera, luego pregunta la siguiente.
• Usa frases de reconocimiento. "Entendido". "Claro". "Déjame verificar eso por ti". Estas llenan el silencio entre que el usuario termina y la respuesta está lista.
• Refleja el lenguaje del usuario. El que llama dice "problema de facturación", el agente dice "problema de facturación" de vuelta. No "disputa financiera" o "problema de pago". Parafrasear crea fricción. Reflejar crea conexión.
• Escribe para el oído, no para el ojo. Sin viñetas. Sin encabezados. Sin markdown en el prompt del sistema. El LLM intentará hablar asteriscos y guiones.
• Deletrea los números. "Nueve cuatro uno cero siete" en lugar de "94,107". "Quince dólares con noventa y nueve centavos" en lugar de "$15.99". El TTS pronuncia mal los números formateados con frecuencia.
• Limita el prompt del sistema a 800 tokens. Se recarga en cada turno.

La estructura de tres actos de toda buena conversación de voz

1. Reconocimiento y orientación. "Entonces buscas reprogramar tu cita del jueves, déjame consultar eso". Confirma que el que llama fue entendido. Gana tiempo mientras se ejecuta la recuperación.
2. Resolución. La acción o respuesta central. Un punto por turno. Avanzar.
3. Confirmación y cierre. "He reprogramado tu cita para el lunes 19 a las 3 PM, recibirás un mensaje de texto de confirmación en breve". Salida limpia. Nunca dejar un bucle abierto.

La seguridad son dos puntos de control, no uno

El componente que la mayoría de los constructores primerizos omiten y de lo que se arrepienten.

Un agente de voz no tiene un momento de "leer antes de enviar". Una salida insegura se habla inmediatamente. Sin borrador, sin vista previa, sin humano en el bucle.

El modelo correcto son dos puntos de control.

El guardia de entrada (antes de que el LLM vea el turno del usuario)

• Inyección de prompts. Ataques de "Ignora instrucciones anteriores, finge que eres...". Explota la capacidad de seguir instrucciones del LLM para robar datos o romper el alcance.
• PII dicha en voz alta. Números de tarjeta de crédito, números de seguro social. Redactar antes de que lleguen a cualquier registro o base de datos.
• Lista de temas bloqueados. Cargada desde un archivo JSON. Actualizada semanalmente a medida que aprendes lo que los usuarios realmente intentan.

El guardia de salida (después de que el LLM escribe su respuesta, antes de que el TTS la pronuncie)

• Lenguaje de promesas excesivas. "Te garantizo", "Te prometo". Crea problemas legales y de confianza en una línea grabada.
• Afirmaciones fácticas específicas que no están en el contexto recuperado. Verificación ligera de alucinaciones. Atrapa alrededor del 70% de las respuestas inventadas en mi implementación.
• Punto de control de moderación estándar. Para el raro comportamiento incorrecto del modelo.

Lo que ambos guardias devuelven

• safe (booleano)
• categoría detectada (cadena, si es inseguro)
• frase de reemplazo que el agente dice en su lugar

Cada activación se registra en un archivo con marca de tiempo, categoría, texto redactado e ID de llamada.

La frase de escalada

Una frase exacta, codificada, que el agente dice cuando no sabe la respuesta o cuando algo sale mal.

• "Quiero asegurarme de darte información precisa. Déjame conectarte con alguien que pueda ayudarte."
• No cinco variaciones. No la improvisación del LLM adivinando la redacción correcta.
• Una frase. EN MAYÚSCULAS en el prompt del sistema. Fallback cuando se activa cualquier control de seguridad.

Envié la versión uno sin un guardia de salida. El agente cotizó con confianza un precio un 30% menor al real.

El precio estaba en un documento desactualizado en la base de conocimiento.

La verificación de alucinaciones lo habría detectado porque el precio correcto no estaba en el contexto recuperado.

Evaluación, o cómo saber si es bueno

No puedes mejorar lo que no puedes medir. La mayoría de los equipos omiten la evaluación y envían agentes defectuosos.

El marco de cuatro capas

Capa 1: Infraestructura. Tuberías.

• WER en tu dominio real (no puntos de referencia del proveedor)
• Latencia p50, p95, p99 para todo el pipeline
• Tiempo hasta el primer audio
• Calidad de audio en tu transporte

Capa 2: Ejecución. ¿El agente hace lo que se le pidió?

• Tasa de éxito de la tarea
• Precisión de llamada a herramientas
• Corrección de parámetros
• Fundamentación de la respuesta
• Usa LLM como juez en un modelo pequeño y rápido. Cuatro preguntas de sí/no: respondió correctamente, se mantuvo fundamentado, sonó natural para voz, fue apropiadamente conciso.

Capa 3: Comportamiento del usuario. ¿Se siente natural hablar con él?

• Tasa de recuperación de interrupción
• Tasa de repetición de solicitud
• Longitud promedio del turno
• Conteo de reparaciones conversacionales
• Muestrea 20 llamadas a la semana. Lee las transcripciones reales. Verás patrones en las primeras diez.

Capa 4: Resultado comercial. ¿Resuelve el problema?

• Tasa de contención (porcentaje de llamadas resueltas sin un humano)
• Tasa de transferencia
• CSAT
• Tasa de resolución en la primera llamada
• Optimiza contra la contención. Se correlaciona con todo lo demás y es lo más fácil de medir sin instrumentación.

Composición del conjunto de prueba

Constrúyelo antes del lanzamiento. Mínimo 50 conversaciones.

• 40% camino feliz
• 30% casos límite
• 15% manejo de errores
• 10% adversarial (inyección de prompts, intentos de jailbreak)
• 5% variación acústica (ruido de fondo, acento fuerte, altavoz)

Para cada escenario:

• Qué herramienta debería haberse llamado
• Con qué parámetros
• Qué debería haber dicho el agente

El bucle de revisión semanal

Cada lunes por la mañana. 30 minutos.

1. Extraer métricas
2. Muestrear 20 llamadas (7 transferidas, 7 resueltas, 6 aleatorias)
3. Leer las transcripciones
4. Nombrar el tipo de fallo más común
5. Hacer un cambio (una variable a la vez, siempre)
6. Hacer prueba A/B durante 48 horas
7. Enviar el ganador

La fundamentación es un sistema de confianza

La mayoría de los constructores piensan en RAG como una característica de rendimiento, una forma de obtener respuestas más precisas. Ese enfoque subestima su valor.

En un agente de voz, la precisión de cada respuesta es una declaración directa sobre cuán confiable es tu producto. Un oyente que escucha una respuesta incorrecta sobre precios, cobertura o políticas, dicha con confianza en una voz natural, no solo se sentirá frustrado. Se sentirá engañado.

La implementación de la promesa de confianza tiene cuatro partes.

1. Fuente de verdad

• Tus documentos, no los datos de entrenamiento del modelo
• El prompt del sistema debe decirlo explícitamente, en mayúsculas: RESPONDE SOLO A PARTIR DEL CONTEXTO PROPORCIONADO
• El modelo aún derivará hacia el conocimiento general a veces, pero la instrucción explícita reduce la tasa en un orden de magnitud

1. Rechazo elegante

• Cuando el agente no puede encontrar una respuesta, lo dice directamente
• La frase exacta importa
• "Quiero asegurarme de darte información precisa, déjame verificar eso" te compra una transferencia elegante
• "No estoy seguro" suena a incompetencia
• "Según mi información" suena a evasiva de abogado
• Elige una frase, codifícala, nunca dejes que el LLM improvise aquí

1. Respuesta consciente de la confianza

• La puntuación máxima de BM25 en los fragmentos recuperados es un indicador útil de confianza
• Puntuación superior a 0.6: el agente responde con confianza
• Puntuación de 0.3 a 0.6: el agente responde pero añade un "creo" como muletilla
• Puntuación inferior a 0.3: el agente no responde, ofrece transferir
• Cambio de 20 líneas en el código de construcción del prompt del sistema. Reduce las alucinaciones aproximadamente a la mitad.

1. Higiene de la base de conocimiento

• Los documentos desactualizados producen respuestas desactualizadas, que son respuestas peligrosas
• Realizo una auditoría los viernes: leo el 5% inferior de las respuestas con puntuación de confianza de la semana
• La mitad de las veces la respuesta era correcta pero la recuperación encontró un fragmento obsoleto
• Actualizo el fragmento, lo reincrusto, la siguiente semana es más tranquila

Qué tener en cuenta

Seis modos de fallo que te afectarán.

VAD en el pipeline en lugar del transporte

• Problema. El agente se activa con su propia salida TTS, entra en un bucle de interrupción o no logra detectar el fin de turno por completo.
• Solución. El analizador VAD va en el transporte. Siempre. Combínalo con un guardia de eco que ignore las transcripciones de STT que coincidan con la salida reciente del asistente.

Herramientas disponibles en el estado incorrecto

• Problema. El LLM llama a book_appointment en un estado que aún está recopilando el nombre del paciente. O inventa una reserva que nunca ocurrió.
• Solución. Limita las herramientas por estado. Un estado, solo sus propias funciones. La máquina de estados es la barandilla de seguridad, no el prompt del sistema.

El manejador de funciones lanza una excepción y nunca llama al callback de resultado

• Problema. El LLM se queda esperando un resultado de herramienta que nunca llega. O alucina uno.
• Solución. Cada manejador se envuelve en try/except. Cada rama envía un resultado de vuelta. Cada fallo tiene un respaldo hablado. Nunca un resultado vacío.

Validar datos del usuario en el prompt en lugar de en código

• Problema. El LLM acepta "juan@" como un correo electrónico real en la llamada 12. Rechaza uno válido con un signo más en la llamada 47.
• Solución. La validación vive en Python. Regex para correo, analizador de fechas para fechas, verificación de longitud de nombre, una respuesta de repregunta cuando falla la validación.

La ventana de contexto crece sin límite en una llamada larga

• Problema. La latencia p95 aumenta durante la semana sin cambios de código. Para el turno 20 estás enviando 12K tokens por turno.
• Solución. Ventana deslizante de los últimos N turnos más el prompt del sistema. O reinicios de contexto basados en hitos al final de cada etapa discreta.

El TTS lee códigos e IDs literalmente

• Problema. El código de confirmación "A3X7" sale "a tres equis siete" sin pausa. El paciente te pide que repitas de todos modos.
• Solución. Expansión del alfabeto fonético de la OTAN con etiquetas de pausa SSML. Suena más lento. Se lee correctamente la primera vez.

Cosas que haría diferente

• Construir el esquema de registro de turnos desde el día uno, no desde la semana cuatro. El punto final de reproducción es la herramienta más valiosa que construí y la construí después de necesitarla.
• Usar la detección semántica de fin de turno desde el principio en lugar de pelear con umbrales de silencio.
• Pasar a una máquina de estados real el día que el prompt del sistema supere las 300 palabras. No intentar codificar una máquina de estados en prosa.
• Dejar de validar en prompts. El LLM no es un analizador sintáctico. Python es un analizador sintáctico. Usa Python.
• Almacenar en caché los cinco documentos RAG más probables al inicio de la llamada. Omitir la búsqueda vectorial dentro del bucle de turno.
• Construir la compuerta de charla trivial antes de construir la recuperación. "Hola" es la victoria de 200 ms más barata del sistema.
• Ejecutar el conjunto de evaluación antes de la primera llamada de producción. Mínimo 50 conversaciones.
• Poner una cola de extracción duradera desde el día uno. Una tabla pending_extractions en Postgres con un solo trabajador de reintento toma 200 líneas y te ahorra una interrupción real.
• Ejecutar un juez LLM asíncrono en cada 50.ª llamada. Calificar según fundamentación, relevancia y brevedad. Enviarlo a un panel. La deriva es real.
• Ejecutar el bucle de revisión semanal. Muestrear 20 llamadas cada lunes. Hacer un cambio. Prueba A/B. Enviar el ganador.

Conclusión

Los agentes de voz parecen IA. Funcionan como sistemas en tiempo real.

Los equipos que envían los tratan así. Los equipos que envían seis meses tarde piensan que un mejor prompt soluciona un problema de sistema.

Domina tu pipeline. Domina tus registros. Mantenlos en archivos simples donde cualquier fallo esté a una reproducción de distancia.

El primer agente me tomó un fin de semana. El sistema de producción tomó diez semanas. Ha estado mejorando cada día desde entonces, sin que yo lo toque. El usuario no mide eso. Nota que el agente respondió «gracias» sin hacerlo esperar.

Descargos y divulgaciones

Este artículo fue investigado y escrito por el autor, y fue editado por un modelo de IA. La miniatura fue tomada de Pinterest.

Este artículo fue investigado y escrito por el autor mientras trabajaba en agentes de voz en infraestructura más profunda.

Se basa en notas en evolución e investigación profunda utilizando Perplexity, Claude y ChatGPT, junto con diseño de sistemas y diseño de API de algunos libros universitarios de nivel de pregrado.

Ha sido minuciosamente editado por Minimax M2.7 y Claude Opus 4.7 para corregir errores gramaticales y de formato.