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

Aquí está la verdad que nadie le dice a los constructores de IA. Los agentes de voz no necesitan el mejor modelo. Todo lo que necesitan es

TLDR; si leer te parece aburrido o tu capacidad de atención está quemada, 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 construir es:

• Un pipeline en tiempo real con un presupuesto de latencia real
• Cinco componentes cableados en el orden correcto
• Una base lo suficientemente sólida para mantener al modelo honesto
• 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 cables y qué le escribes al agente que diga.

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 compilación sonaba como un quiosco. La eliminé en dos días.
• La segunda compilación "reservó" cuatro citas fantasma en la primera hora antes de que me diera cuenta.
• La tercera compilación perdió 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 pequeño conjunto de propiedades que explicaré en las próximas 6000 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 agente dual, 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 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 esos 90 días realmente me enseñaron, más las dos o tres apuestas que haría primero si empezara de nuevo hoy.🔽🔽

Qué es realmente un agente de voz

Un agente de voz no es un chatbot con un micrófono acoplado. No es un envoltorio TTS para 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 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 cambiar.

Primero intenté construirlo como un chatbot. El STT completa, enviar al LLM, esperar la respuesta completa, enviar al TTS, esperar el audio completo, reproducir.

Se sintió horrible. Como hablar con un quiosco. A los dos días lo borré.

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 frase.
• El TTS tiene que empezar a hablar antes de que el LLM haya terminado 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 STT, LLM y TTS separados cableados juntos
• Tres modelos independientes, cada uno especializado en su trabajo
• El texto fluye entre ellos
• La latencia ronda los 600 a 700 ms en una plataforma gestionada bien ajustada
• El más controlable, el más depurable, el 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
• Captura la frustración en la voz de alguien, una pregunta implícita por un tono ascendente, un cambio de idioma a mitad de frase
• La salida aún se enruta a través de un TTS especializado para el control de audio
• La latencia baja a 300 a 500 ms

Voz nativa a voz

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

Con cuál empezar

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

Los cinco componentes que debes cablear

Cada pipeline encadenado tiene los mismos cinco componentes. Cinco trabajos 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 termina.
• Tasa de error de palabras. 6 a 8% en audio de producción real es bueno. Más del 12% frustrará a los usuarios en cada tercera llamada.
• 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 ella, tu agente interrumpe a mitad de frase o espera dos segundos incómodos.
• La ola de 2026 de modelos STT en streaming 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 completo cuando ha decidido que el hablante ha terminado.
• La señal usa contexto semántico, no solo silencio acústico. Captura la voz que se desvanece e ignora las pausas para respirar.
• 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 frontera tardan 1500 ms en generar la primera palabra. Eso es aire 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 necesitan una planificación real.
• Limita el mensaje del sistema a 800 tokens. Se recarga en cada turno. Un mensaje de 4000 tokens añade latencia a cada mensaje.

Llamada de 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 la llamada de funciones no es lo que esperarías:

• El LLM no lanza un error cuando no puede llamar a una función. En cambio, narra la acción.
• "He confirmado tu reserva." No se llamó a nada. El usuario cree que está reservado. No lo está.
• La solución es delimitar 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 el riel de seguridad, no el mensaje del sistema.

El conocimiento (RAG)

RAG es el mecanismo que permite que tu agente responda 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 de corte.
• Saben mucho sobre el mundo. No saben nada específico sobre tus productos, precios, políticas, clientes.
• Sin RAG, un agente al que se le pregunta "¿qué hay en 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 instruye al LLM para que responda solo desde 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 agente dual. Sección completa sobre esto a continuación.

La boca (TTS)

El TTS convierte texto en audio hablado. Suena simple. En realidad es un gran diferenciador en la calidad percibida.

Qué importa:

• Tiempo hasta el primer audio. Un TTS que tarda 200 ms en empezar a hablar quema un tercio de tu presupuesto de latencia solo en la capa de salida.
• Calidad de voz. Los humanos son extraordinariamente sensibles al habla sintética. Artefactos sutiles, ritmo poco natural, acentos mal colocados: todo se lee 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 dramáticamente 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 no obvio sobre los agentes de voz: cada milisegundo de tiempo de procesamiento es un milisegundo de silencio que el que llama soporta.

Las matemáticas:

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

Ese margen de 700 ms es 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 relays.
• STT primer intermedio. 100-150 ms en acierto de caché. 150-250 ms en fallo.
• Detección de fin de turno. Integrada en el modelo, ~50 ms. Umbral de silencio, 300-600 ms.
• Recuperación RAG. Menos de 1 ms en acierto de caché. 80-150 ms en BM25 local + reordenamiento.
• LLM tiempo hasta primer token. 150-250 ms con un modelo pequeño. 400-600 ms con un modelo frontera.
• TTS tiempo hasta primer audio. 60-100 ms en el nivel rápido. 150-250 ms en el nivel de calidad.
• Sobrecarga de red. 40-80 ms total dentro de una región. 100-160 ms total entre regiones.
• Extremo a extremo. ~440 ms en el carril rápido. ~700-900 ms en el carril lento.

Los dos mayores avances en 2026:

1. Detección de fin de turno integrada en el modelo. Elimina de 200 a 400 ms de cada turno. La mejora única más grande que puedes hacer este año.
2. Prebúsqueda especulativa con caché de agente dual. Pasa 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 es error de redondeo en comparación con esos dos.

El patrón RAG de agente dual

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

La respuesta de 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
• Precarga fragmentos de documentos relevantes para cada predicción
• Los almacena en un caché local en memoria antes de que el usuario haya terminado de escuchar la respuesta actual

El agente de 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 para 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 almacena 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é
• 316× de aceleración en la recuperación en aciertos de caché (0.35 ms vs 110 ms)
• 16 segundos de latencia acumulada ahorrada 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 compilación. Añadió 110 ms por turno. Mató la sensación de conversación. Cambié al patrón de caché de agente dual en la semana seis. El 40% de los turnos que aciertan en el caché se sienten más rápidos que los representantes humanos del centro de llamadas que el agente 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. El lapso de atención humano 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 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". No "disputa financiera" o "problema de pago". Parafrasear crea fricción. Reflejar crea rapport.
• Escribe para el oído, no para el ojo. Sin viñetas. Sin encabezados. Sin Markdown en el mensaje del sistema. El LLM intentará hablar asteriscos y guiones.
• Escribe los números con letras. "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.
• Limita el mensaje 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 quieres reprogramar tu cita el jueves, déjame consultarlo." 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 confirmación en breve." Salida limpia. Nunca dejes un bucle abierto.

La seguridad son dos puntos de control, no uno

El componente que la mayoría de los constructores primerizos omiten y lamentan.

Un agente de voz no tiene un momento de "leer antes de enviar". Una salida insegura se pronuncia 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 prompt. Ataques de "Ignora las instrucciones anteriores, finge que eres...". Explota la capacidad del LLM de seguir instrucciones para robar datos o romper el alcance.
• PII dicha en voz alta. Números de tarjeta de crédito, números de seguridad social. Redactar antes de que lleguen a cualquier registro o base de datos.
• Lista de bloqueo de temas. 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 no presentes en el contexto recuperado. Verificación ligera de alucinaciones. Captura alrededor del 70% de las respuestas inventadas en mi despliegue.
• Endpoint de moderación estándar. Para el raro mal comportamiento del modelo.

Lo que ambos guardias devuelven

• safe (booleano)
• detected category (cadena, si no es seguro)
• replacement phrase (la 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 escalado

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

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

Envié mi primera compilación sin un guardia de salida. El agente cotizó con confianza un precio un 30% inferior al real. El precio estaba en un documento desactualizado en la base de conocimientos. 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 rotos.

El marco de cuatro capas

Capa 1: Infraestructura. Plomería.

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

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

• Tasa de éxito de la tarea
• Precisión de la 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 mantuvó 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 re-pregunta
• Longitud promedio del turno
• Recuento de reparaciones conversacionales
• Muestrea 20 llamadas a la semana. Lee las transcripciones reales. Verás patrones en menos de diez.

Capa 4: Resultado de negocio. ¿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 de lanzar. Mínimo 50 conversaciones.

• 40% camino feliz
• 30% casos extremos
• 15% manejo de errores
• 10% adversario (inyección de prompt, 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. Extrae métricas
2. Muestrea 20 llamadas (7 escaladas, 7 resueltas, 6 aleatorias)
3. Lee las transcripciones
4. Nombra el tipo de fallo más común
5. Haz un cambio (una variable a la vez, siempre)
6. Pruébalo A/B durante 48 horas
7. Implementa 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 encuadre lo subestima.

En un agente de voz, la precisión de cada respuesta es una declaración directa sobre cuán confiable es tu producto. Un usuario que escucha una respuesta incorrecta sobre precios, cobertura o política, 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 mensaje del sistema debe decirlo explícitamente, en mayúsculas: RESPONDE SOLO DESDE EL CONTEXTO PROPORCIONADO
• El modelo aún se desviará 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 un abogado
• Elige una frase, codifícala, nunca dejes que el LLM improvise aquí

1. Respuesta basada en confianza

• La puntuación máxima de BM25 en los fragmentos recuperados es un proxy útil para la 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 una muletilla "creo"
• 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 mensaje del sistema. Reduce las alucinaciones aproximadamente a la mitad.

1. Higiene de la base de conocimientos

• Los documentos desactualizados producen respuestas desactualizadas, que son respuestas peligrosas
• Ejecuto 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
• Actualiza el fragmento, vuelve a incrustarlo, la semana siguiente es más tranquila

Qué vigilar

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 detecta el final del turno en absoluto.
• Solución. El analizador VAD va en el transporte. Siempre. Combínalo con un guardia de eco que ignore las transcripciones 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á recogiendo el nombre del paciente. O inventa una reserva que nunca ocurrió.
• Solución. Limita las herramientas por estado. Un estado, solo sus funciones. La máquina de estados es el riel de seguridad, no el mensaje 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 fallback hablado. Nunca un resultado vacío.

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

• Problema. El LLM acepta "juan@" como un correo 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. Expresión regular 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 se desplaza hacia arriba 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 mensaje del sistema. O reinicios de contexto basados en hitos al final de cada etapa discreta.

El TTS lee códigos e ID literalmente

• Problema. El código de confirmación "A3X7" sale "a tres equis siete" sin pausa. El paciente te pide que lo repitas de todas formas.
• 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 el día uno, no la semana cuatro. El endpoint de reproducción es la herramienta más valiosa que construí y la construí después de necesitarla.
• Usar detección semántica de fin de turno desde el principio en lugar de luchar con umbrales de silencio.
• Mudarse a una máquina de estados real el día que el mensaje del sistema supere las 300 palabras. No intentes codificar una máquina de estados en prosa.
• Dejar de validar en los 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 turnos.
• Construir la compuerta de charla trivial antes de construir la recuperación. "Hola" es la ganancia 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 de extracciones_pendientes en Postgres con un trabajador de reintento único toma 200 líneas y te ahorra una interrupción real.
• Ejecutar un juez LLM asíncrono en cada 50.ª llamada. Puntuar en fundamentación, relevancia, 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. Implementar el ganador.

Conclusión

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

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

Sé dueño de tu pipeline. Sé dueño de 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. Desde entonces ha mejorado cada día, sin que yo tenga que tocarlo. El usuario no mide eso. Nota que el agente respondió «gracias» sin hacerle esperar.

Exenciones de responsabilidad 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 usando 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.