Cómo crear agentes de voz duraderos: lecciones aprendidas desde la ingeniería en despliegues reales

En la mayoría de organizaciones, las soluciones puntuales para el soporte siempre se han medido por su capacidad de desviar consultas. Es decir, reducir el volumen de llamadas y minimizar la interacción con agentes en directo. Pero desviar no es lo mismo que resolver, y esa diferencia es donde la experiencia del cliente se resiente. Para cerrar esa brecha, los agentes necesitan acceso no solo a los datos, sino también a los sistemas que les permitan actuar. Así, pueden procesar reembolsos, guiar a clientes durante el proceso de compra y transferir la conversación a un agente humano con todo el contexto cuando sea necesario. Esto permite a las empresas gestionar interacciones con clientes a gran escala, reduciendo de forma significativa la carga sobre los equipos de soporte y mejorando la experiencia para ambas partes de la llamada.En un despliegue reciente con Revolut, una fintech que atiende a 70 millones de clientes en todo el mundo, esto se tradujo en una reducción de 8 veces en el tiempo de resolución y una tasa de éxito del 99,7% en llamadas.

Las organizaciones deben abordar cambios de este calibre de forma iterativa, alineados con la misión principal de la empresa y con apoyo claro de la dirección. A nivel técnico, razonar en entornos no estructurados implica riesgos que hay que gestionar con cuidado. Dar a un agente la capacidad de actuar sobre el CRM, modificar un pedido en el sistema de punto de venta o escalar un caso significa que el modelo de gobernanza es tan importante como el propio modelo. El foco ya no es si los agentes pueden gestionar tareas reales, sino qué mecanismos hacen falta para desplegarlos de forma segura y repetida.

En este artículo compartimos, desde nuestra experiencia, qué hace que un agente tenga éxito desde el primer despliegue hasta el escalado en toda la operación de atención al cliente.

Desplegar agentes vs. desplegar software

Antes de profundizar en la creación de agentes, merece la pena comparar el despliegue de agentes de voz con el software tradicional, algo que las empresas llevan décadas haciendo. Desde este punto de vista, los agentes se dividen en dos componentes: software tradicional y orquestador central.

Software:

Software: observabilidad y gobernanza

Orquestador central

Los componentes del Orquestador principal son, por naturaleza, más difíciles de predecir, pero determinan el rendimiento en tiempo real del agente tanto en calidad de respuesta como en latencia percibida. A diferencia del software tradicional, estos componentes trabajan sobre lenguaje natural y audio, donde el espacio de entrada es prácticamente ilimitado y pequeños cambios en la formulación, el contexto, el ruido de fondo o el comportamiento del usuario pueden generar resultados muy distintos con el tiempo. Por eso, las pruebas convencionales no son suficientes: un agente puede funcionar perfectamente en cientos de pruebas y aun así fallar en producción de formas difíciles de anticipar.versionado, Pruebas A/B, telefonía y configuración del primer mensaje, entre otras. Estos componentes apenas cambian tras el despliegue, lo que hace que su comportamiento sea muy predecible. Con buenas prácticas de ingeniería, las organizaciones pueden construir sobre estas funciones rápidamente y mantener un control profundo de su rendimiento en producción gracias a métricas, trazas y logs. Las mejoras de latencia en esta capa siguen patrones conocidos: caché, agrupación de conexiones, escalado de infraestructura y optimización de protocolos son palancas fiables con resultados deterministas.

La latencia en esta capa también es menos predecible, ya que depende de los tiempos de inferencia del modelo, la aparición de artefactos sonoros, cadenas de herramientas y la variabilidad propia de los sistemas generativos. Gestionar bien estos componentes requiere otra disciplina, basada en marcos de evaluación, monitorización en producción y la voluntad de iterar continuamente a partir de datos reales de conversaciones, no solo de suposiciones previas al despliegue.

Esta diferencia marca cómo deben abordar las organizaciones la adopción: empezar por casos de uso relevantes pero de bajo riesgo, y escalar de forma deliberada a medida que crece la confianza en el sistema.

Ciclo de lanzamientos

Elegir casos piloto

Para los equipos que empiezan a usar agentes de voz, elegir bien los casos piloto es una de las decisiones más importantes al principio. Y suele tener menos que ver con la tecnología de lo que se piensa. Los equipos que logran éxitos tempranos y evitan quedarse atascados en pruebas de concepto suelen tener algo en común: pueden responder con claridad a las siguientes preguntas.

Para los equipos que empiezan a usar agentes de voz, elegir bien los casos piloto es una de las decisiones más importantes al principio. Y tiene menos que ver con la tecnología de lo que parece. Los equipos que logran éxitos tempranos y evitan quedarse atascados en pruebas de concepto suelen tener algo en común: pueden responder con claridad a estas preguntas.

• ¿Cómo aporta valor real este caso de uso al negocio? El caso de uso ideal para empezar no es el más interesante técnicamente, sino el que más puede influir en un resultado que ya importa a la empresa. Esto se mide por impacto en ingresos, reducción de costes, satisfacción del cliente y otras métricas que los responsables ya siguen y por las que rinden cuentas. Sin esa conexión directa con el valor de negocio, es difícil justificar los ciclos de iteración necesarios para afinar el agente, y el impulso se pierde antes de que la tecnología demuestre su valor.
• ¿Está claro para los usuarios cuál es el alcance y objetivo del agente?La ambigüedad en el alcance es una de las causas más comunes de desviaciones entre desarrollo y producción. Si los usuarios no entienden qué puede y qué no puede hacer un agente, pondrán a prueba sus límites de formas que nunca se contemplaron en las pruebas. Un agente bien definido marca expectativas desde el primer mensaje y gestiona con naturalidad las peticiones fuera de su alcance.
• ¿Cómo son las buenas y malas interacciones, y se pueden convertir en criterios de evaluación concretos?Una buena interacción no es solo que el agente complete la tarea, sino que el usuario se sienta escuchado, que la escalada ocurra en el momento adecuado y que el resultado esté alineado con el objetivo del negocio. Los criterios de evaluación se dividen en dos: métricas cuantitativas recogidas por la plataforma, como tasa de tareas completadas y de escalado, y criterios basados en transcripciones que requieren analizar la conversación. Definir estos criterios desde el principio da al equipo un objetivo claro. También marcan el umbral natural para salir a producción. Cuando el agente cumple sus criterios de evaluación de forma constante y las métricas de plataforma se estabilizan, hay confianza para pasar a producción. Sin criterios definidos, la decisión de lanzar es subjetiva.
• ¿Cuáles son los equilibrios entre rendimiento y control, y cuál importa más en este momento?Cuanta más autonomía tiene un agente, más naturales y flexibles son las interacciones, pero también aumenta el riesgo de que actúe fuera de los límites validados. Un control más estricto mediante prompts limitados y lógica de escalado rígida reduce ese riesgo, pero puede hacer que el agente resulte artificial. Ningún extremo es ideal. Si se restringe demasiado pronto, el resultado es un IVR glorificado. Si se avanza demasiado rápido sin establecer confianza, se generan cargas de soporte que anulan los beneficios. Saber dónde situar este equilibrio en cada fase de madurez influye en la configuración del modelo, la lógica de escalado y en cuánto conocimiento del agente está en el prompt frente a fuentes estructuradas o recuperadas.

Definir la base del desarrollo inicial

Al pasar a la ejecución, los equipos pueden apoyarse en metodologías casi tan antiguas como el propio software. El desarrollo guiado por pruebas (TDD) ofrece la estructura para mantener a los agentes alineados con las métricas clave durante todo el desarrollo.

Al pasar a la ejecución, los equipos pueden apoyarse en metodologías casi tan antiguas como el propio software. El desarrollo guiado por pruebas (TDD) sirve de base para mantener a los agentes alineados con las métricas clave durante todo el proceso.

Con un conjunto inicial de pruebas, el desarrollo del agente empieza por el prompt del sistema. Aquí se definen las reglas, el tono y el enfoque del agente: qué debe hacer, qué no debe hacer y cómo debe comportarse en los límites de su función. Un prompt bien diseñado es tanto cuestión de estructura como de contenido. Separar las instrucciones en secciones claras, agrupar las indicaciones relacionadas y evitar frases condicionales marcan la diferencia en la consistencia del agente. En esta fase, solemos volver a la guía de prompts.Pruebas del agente, que verifican de forma repetida los comportamientos que se espera que tenga el agente. Los primeros se basan en revisar llamadas reales de humanos cuando ya existen. Las segundas se construyen poco a poco, empezando por un conjunto inicial de comportamientos esperados y ampliando a medida que surgen nuevos y se descubren casos límite.

Junto al prompt del sistema, se configuran los componentes principales del agente: el LLM, el modelo de texto a voz (TTS) y la voz. La elección del LLM es sobre todo un equilibrio entre latencia y rendimiento: los modelos optimizados para velocidad suelen sacrificar algo de capacidad de razonamiento, y viceversa. Para TTS, la mejor opción depende de lo que más requiera el caso de uso: entonación expresiva, baja latencia o soporte multilingüe. La voz, sin embargo, es tanto una decisión de marca como técnica. Define cómo perciben a la organización quienes llaman, por lo que es una de las pocas decisiones de configuración que corresponde tanto a equipos de marca y marketing como a los ingenieros que desarrollan el agente. Esto significa que la selección de voz puede hacerse en paralelo al resto del desarrollo, en vez de convertirse en un cuello de botella al principio o al final. ElevenAgents ofrece acceso a más de 10.000 voces, y si ninguna encaja, los equipos pueden clonar o crear la suya propia.

A partir de aquí, los agentes pueden ampliarse opcionalmente con una Base de Conocimiento,

Con estas bases, el agente está listo para ser puesto a prueba.base de conocimiento, herramientas y configuraciones de canal. Cada añadido desbloquea nuevas capacidades, pero también introduce nuevas áreas que probar. Ya sea integración con telefonía, acceso a bases de datos externas o la capacidad de actuar en nombre de un cliente, estas decisiones conviene ponerlas a prueba frente a los criterios de evaluación antes de ampliar el alcance. Cuando se añaden herramientas, el prompt del sistema y la descripción de la herramienta indican explícitamente cuándo y cómo usarlas, para que el agente las utilice siempre de forma coherente y en el contexto adecuado.

Preparando la salida a producción

Con las pruebas y los criterios de evaluación definidos en la fase inicial ya ejecutándose sobre un agente construido, el desarrollo se convierte en un ciclo cerrado: añadir más pruebas, identificar fallos, actualizar el prompt del sistema o la configuración y volver a probar. La mayoría de los fallos en esta fase no son del modelo, sino del prompt. Una instrucción que parecía clara por sí sola resulta ambigua cuando el agente la encuentra en mitad de una conversación. Surgen casos límite que la batería de pruebas inicial no anticipó. Cada uno se convierte en una nueva prueba Next Turn que puede crearse a partir de la propia conversación. La pregunta de cuándo dejar de iterar tiene una respuesta concreta: cuando el agente cumple sus criterios de evaluación de forma constante en varias ejecuciones y las métricas de la plataforma, como la tasa de tareas completadas y de escaladas, se estabilizan en rangos aceptables. Por eso es tan importante definir esos criterios antes de construir. Sin ellos, la preparación para producción es subjetiva y la meta se mueve constantemente.

En la práctica, la mayoría de los equipos descubren que un pequeño grupo de patrones de fallo recurrentes explica la mayoría de los problemas. Los más comunes son la ambigüedad en el prompt, cuando el agente recibe instrucciones contradictorias o poco claras y actúa de forma impredecible; el mal uso de herramientas, cuando el agente usa una herramienta en el contexto equivocado o no la usa cuando debería; y la desviación en la escalada, cuando el agente escala demasiado rápido o retiene conversaciones que debería haber derivado. Cada uno de estos problemas se soluciona a nivel de prompt: afinando la instrucción relevante, añadiendo un ejemplo explícito o ajustando el umbral de escalada suele ser suficiente. El riesgo está en no detectarlos antes de salir a producción.

El error más común es tratar una batería de pruebas superada como una garantía en vez de una señal. Un conjunto de pruebas que solo cubre el caso ideal pasará fácilmente y no significará gran cosa. La cobertura de rechazos, cambios de rumbo en mitad de la conversación, entradas ambiguas e interacciones con muchas herramientas es lo que da peso a los resultados. De igual forma, los equipos que se saltan las pruebas de simulación y solo usan pruebas por turnos se pierden una clase de fallos que solo aparecen en conversaciones completas, como la pérdida de contexto, cuando el agente olvida turnos anteriores, o errores acumulativos, cuando un pequeño fallo al principio de la llamada acaba en un mal resultado. Una vez resueltos los patrones de fallo recurrentes y el agente gestiona los casos límite de forma natural (no perfecta), el valor de seguir iterando en staging disminuye. En ese punto, la señal más valiosa viene de conversaciones reales.

Salir a producción no significa que se acabe la iteración. Significa que el aprendizaje pasa de pruebas sintéticas a transcripciones reales. Los criterios de evaluación que definieron la salida a producción se convierten en la referencia para medir el rendimiento en vivo, y el ciclo continúa desde ahí.

Ciclos de feedback, evaluación y saber cuándo parar de iterar

Una vez definidas y en marcha las pruebas, las carencias en el proceso se detectan rápido. Con la

La disciplina más importante en esta fase es validar los cambios, no darlos por hechos. Una solución que arregla un fallo puede introducir otro sin que se note. ElevenAgents permite el versionado, lo que permite probar nuevas iteraciones con un pequeño porcentaje de usuarios antes de desplegarlas a todos. Así se puede confirmar que las mejoras realmente mejoran los resultados y no desplazan el problema a otro sitio.

Qué puede salir malversionado, así los equipos pueden probar nuevas iteraciones con un pequeño porcentaje de usuarios antes de lanzarlas a todos. Así se puede confirmar que las mejoras realmente mejoran los resultados y no desplazan los fallos a otro sitio.

El mayor error en esta fase es saltarse los despliegues escalonados y aplicar cambios directamente a todos los usuarios. Sin lanzamientos por fases, se pierde la capacidad de aislar el impacto de cada cambio y, a escala, es casi imposible entender qué está mejorando o empeorando las métricas de la plataforma. Tratar a todos los usuarios como entorno de pruebas no solo es arriesgado, sino que elimina la visibilidad necesaria para tomar decisiones con confianza.

Más allá de la estrategia de despliegue, hay dos riesgos más a evitar. El primero es reaccionar en exceso a fallos recientes. Cuando una conversación importante sale mal, es natural querer parchearla rápido y de forma general, pero cambios reactivos en el prompt sin pasar todas las pruebas suelen causar regresiones en comportamientos que antes eran estables. Cada cambio, por pequeño que sea, debe tratarse como una nueva iteración y probarse. El segundo es la relajación de los criterios de evaluación. Con el tiempo, los equipos pueden bajar el listón de lo que consideran una prueba superada, sobre todo bajo presión por lanzar. Los criterios definidos al principio deben seguir siendo la referencia. Si parecen demasiado estrictos, lo correcto es revisarlos y actualizarlos de forma deliberada, no dejar que los estándares se relajen sin control.

Escalar con confianza

Aumentar el tráfico es una decisión basada en la confianza, no en el tiempo. La señal para escalar es cuando el agente cumple sus criterios de evaluación de forma constante en varias pruebas, las métricas de la plataforma se estabilizan y los despliegues escalonados no muestran regresiones relevantes frente al grupo de control.

Una duda habitual en esta fase es cuántas interacciones hacen falta para sacar conclusiones. Lotes de menos de 100 llamadas por rama tienen demasiada variabilidad para evaluar resultados con fiabilidad. Un 60% de éxito en 25 llamadas y un 60% en 100 llamadas no dan la misma confianza. Además de un número mínimo, el lote debe ser lo bastante grande para cubrir toda la variedad de entradas realistas, incluidos casos límite, intenciones poco comunes y fallos que solo aparecen con volumen y rara vez en muestras pequeñas.

Más tráfico amplifica tanto lo que funciona como lo que no. Escalar antes de resolver los fallos principales genera una carga de soporte difícil de revertir.

Itera y repite

Saber cuándo parar es tan importante como saber qué arreglar. La iteración tiene rendimientos decrecientes, y la señal para pausar es cuando el agente cumple de forma constante los criterios de evaluación definidos al principio. A partir de ahí, los cambios adicionales tienen más riesgo que beneficio.

El aspecto de "cumplir criterios de forma constante" varía según el contexto. Equipos con acceso limitado a datos o integraciones incompletas pueden ver tasas de escalada cercanas al 50% como un techo realista hasta resolver esas limitaciones. Donde el acceso a datos es bueno, los despliegues más exitosos suelen buscar más del 80% de tareas completadas y menos del 20% de escaladas. Más importante que cualquier cifra es la estabilidad: rendimiento constante durante varias semanas de tráfico real, sin regresiones relevantes en las pruebas, es la señal clave. Cuando la ganancia de la siguiente iteración es menor que el riesgo de retroceso, es momento de parar.

Eso no significa que el trabajo haya terminado. Cuando surgen nuevos requisitos, el proceso vuelve a empezar desde arriba. Las preguntas de definición del primer desarrollo siguen siendo igual de relevantes para el segundo. La diferencia es que los equipos que entran en un segundo ciclo ya cuentan con una batería de pruebas, una referencia de evaluación y experiencia operativa que en el primer ciclo hubo que construir desde cero. Esa ventaja acumulada es la que separa a las organizaciones que obtienen valor duradero de los agentes de voz de las que se quedan atascadas en pruebas de concepto.

Conclusión

Los equipos que hemos visto cerrar la brecha entre desvío y resolución son los que definen cómo debe ser el éxito antes de empezar a construir, mantienen la disciplina durante la iteración y tratan cada despliegue como la base para el siguiente. Los agentes conversacionales no son un despliegue puntual: las conversaciones reales sacan a la luz casos límite que ninguna batería de pruebas anticipa del todo, y el trabajo de mejora no termina al salir a producción.

ElevenAgents está pensado para esta realidad. Las pruebas de agentes, el análisis de conversaciones y los despliegues escalonados son la base que convierte una prueba de concepto en un sistema que realmente resuelve problemas de clientes a escala, no solo los desvía. Esa es la brecha que merece la pena cerrar.

ElevenAgents está pensado para esta realidad. Las pruebas de agentes, el análisis de conversaciones y los lanzamientos escalonados son la base que convierte una prueba de concepto en un sistema que realmente resuelve problemas de clientes a escala, no solo los desvía. Esa es la brecha que merece la pena cerrar.