Por qué tu agente de voz solo tiene un segundo

Una empresa instaladora de calderas probó su agente de voz durante dos semanas en demos internas. Funcionaba: entendía las preguntas, reservaba la visita técnica, sonaba natural. El día que lo pusieron a atender llamadas reales, los clientes empezaron a interrumpirlo, a hablar por encima, a colgar antes de terminar. El guion era el mismo de las demos. Lo que había cambiado era el contexto: en la oficina, con buena conexión, el agente respondía rápido. En producción, con líneas reales, tardaba casi dos segundos en contestar cada frase.

Dos segundos no parece mucho escrito. En una conversación de voz es una eternidad. Es el tiempo suficiente para que la persona piense que la llamada se ha cortado, repita la frase y pise la respuesta del agente justo cuando esta empieza a sonar. A partir de ahí, todo se desordena.

El diseño conversacional más cuidado no sirve de nada si la infraestructura no puede entregarlo a tiempo. Y el tiempo, en voz, es un recurso fijo que se gasta. Conviene saber cuánto tienes y en qué se va.

El segundo que lo decide todo

Una conversación por voz se siente natural solo cuando la respuesta llega en torno a un segundo. Por debajo de esa cifra, la interacción parece fluida. Por encima, empieza a notarse el hueco, y a partir de ahí la sensación es de algo roto.

No es una opinión estética: es cómo funciona la conversación humana. Cuando hablamos entre personas, los silencios largos significan algo —duda, desacuerdo, que el otro no ha entendido—. Nuestro cerebro está entrenado para leerlos. Cuando un agente deja un silencio de dos segundos después de cada cosa que decimos, lo interpretamos como un fallo, no como que está "pensando".

Por eso la regla práctica es dura y simple: tienes alrededor de 1.000 milisegundos desde que la persona termina de hablar hasta que tu agente empieza a responder. Ese es todo tu presupuesto. Cada decisión técnica gasta de ahí.

Cómo se reparte ese segundo

Un agente de voz no es una sola pieza. Son varias, encadenadas, y cada una consume parte del presupuesto. Un reparto realista de esos 1.000 ms se parece a esto:

• Transcripción (voz a texto): ~200 ms. Convertir lo que ha dicho la persona en texto que el modelo pueda procesar.
• Razonamiento del modelo: ~400 ms. Entender la intención, decidir qué hacer y generar la respuesta.
• Síntesis de voz (texto a voz): ~200 ms. Convertir la respuesta en audio que suene humano.
• Red y telefonía: ~200 ms. El viaje de los datos por la línea telefónica y por internet, ida y vuelta.

Sumado, encaja por los pelos. Y ese "por los pelos" es la clave: no hay margen para el descuido. En cuanto una de esas piezas se pasa de su presupuesto, el total se va por encima del segundo y la conversación se resiente. La telefonía no se puede negociar mucho; el resto, sí.

Dónde se esconde la latencia

Lo difícil no es el reparto teórico. Es que hay retrasos que no aparecen en la demo y sí en producción. Estos son los cuatro sitios donde casi siempre se esconde el tiempo perdido.

1. Prompts demasiado largos

Cuanto más larga es la instrucción que recibe el modelo, más tarda en procesarla. Es tentador meterlo todo en el prompt —el catálogo entero, las cien preguntas frecuentes, las normas de la casa— "por si acaso". Cada palabra de más se paga en cada respuesta, durante toda la llamada. Un prompt de 1.500 palabras no es gratis: añade décimas que salen directas de tu presupuesto.

2. Llamadas a sistemas a mitad de respuesta

Si el agente tiene que consultar el calendario de citas o el CRM antes de contestar, ese tiempo cuenta. Una API interna que tarda 800 ms en responder se convierte en el cuello de botella de toda la llamada, por muy rápido que sea el modelo. La regla aquí es clara: si una herramienta que necesitas sí o sí tarda 300 ms de media, tu presupuesto para el modelo ya no es de 400 ms, es de 100. Hay que presupuestar las herramientas aparte, y definir bien cada una es justo el tema de el contrato entre tu agente y tus sistemas.

3. Un backend que no acompaña

El agente es tan rápido como lo más lento a lo que se conecta. Si tu sistema de gestión responde en milisegundos, perfecto. Si hay que pasar por tres saltos, una base de datos antigua y un servicio que se despierta con calma, el agente espera, y la persona al teléfono también. Esto rara vez se ve en las pruebas, porque en pruebas el backend está descargado. En producción, con cientos de llamadas a la vez, se nota.

4. Generar toda la voz antes de empezar a hablar

Hay dos formas de sintetizar la voz. Una espera a tener la frase entera generada y entonces la reproduce. La otra empieza a reproducir las primeras palabras mientras todavía está generando el resto. La segunda —síntesis en streaming— ahorra entre 100 y 200 ms de espera percibida. No es un detalle técnico menor: es la diferencia entre que el agente "arranque" enseguida o deje un silencio incómodo antes de cada respuesta.

Dos decisiones que recuperan medio segundo

La buena noticia es que dos cambios de arquitectura recuperan buena parte del presupuesto sin tocar el guion.

Síntesis de voz en streaming. Que el agente empiece a hablar en cuanto tiene las primeras palabras, no cuando tiene la frase completa. Solo con esto recuperas hasta 200 ms y la sensación de inmediatez cambia por completo.

Recuperación en lugar de prompt gigante. En vez de meter toda la documentación en la instrucción, se guarda en una base de conocimiento consultable y el agente recupera solo el fragmento relevante para cada pregunta. Esto mantiene el prompt corto —y por tanto el modelo rápido— y solo añade unos 50-100 ms por la consulta. Lo mejor: escala sin penalización. Añadir mil documentos más no ralentiza la respuesta, porque el agente no los carga todos, solo busca el que necesita.

Mide en producción, no en el folleto

Todos los proveedores de transcripción y de voz publican sus tiempos. Casi siempre son los del mejor caso, en condiciones de laboratorio. Lo único que importa es la latencia real, con tu telefonía, tus integraciones y tu volumen. Cien milisegundos de más en un proveedor se comen el 10 % de tu presupuesto total; merece la pena medirlo de verdad antes de comprometerse.

Y ojo con confundir rápido con bueno. Un sistema de transcripción veloz pero impreciso es peor que uno algo más lento y fiable: si entiende mal lo que dice la persona, el agente responde a algo que nadie ha dicho, la persona corrige, y entras en un bucle que destroza la conversación. La precisión es parte del presupuesto de tiempo, aunque no lo parezca.

El presupuesto, en una plantilla

Antes de dar por bueno un agente de voz, pásalo por esta lista. No es burocracia: es lo que separa una demo que impresiona de un agente que aguanta una jornada real.

• ¿La respuesta llega por debajo de un segundo en producción, no en la demo?
• ¿Has medido cada pieza por separado —transcripción, modelo, voz, red— para saber cuál se pasa?
• ¿El prompt es lo más corto posible, con la documentación fuera, en una base de conocimiento?
• ¿Las herramientas que el agente usa sí o sí tienen su propio presupuesto de tiempo medido?
• ¿La voz se reproduce en streaming, sin esperar a generar la frase entera?
• ¿Mides la latencia de forma continua, no solo el día del lanzamiento?

Un agente bien diseñado sobre una infraestructura lenta siempre pierde contra uno más sencillo que responde a tiempo. La conversación solo se siente natural cuando lo que hay debajo puede entregarla sin titubear. El presupuesto de latencia no es un tecnicismo: es la diferencia entre que la gente hable con tu agente o le cuelgue.