El contrato entre tu agente de voz y tus sistemas

Una clínica puso en marcha un agente de voz para reservar citas. La conversación era impecable: educado, claro, rápido. Un martes por la mañana, con la línea un poco lenta, el sistema de reservas tardó en confirmar y el agente volvió a llamarlo. La cita quedó registrada dos veces. Esa misma mañana, tres pacientes distintos recibieron la misma hora del mismo doctor. Cuando llegaron, la sala de espera era un problema.

Nadie había escrito un guion malo. El fallo no estaba en la conversación, estaba en lo que hay debajo: en cómo el agente hablaba con el sistema de citas. La parte que se ve —la voz— funcionaba. La parte que no se ve —el contrato con el backend— no estaba definida.

Y esa es la idea que cambia la forma de construir agentes de voz fiables: tu conversación es la interfaz; tus sistemas son el backend. La voz es la pantalla bonita. El trabajo de verdad ocurre cuando el agente reserva, cobra, da de alta o consulta. Si esa parte no está bien especificada, da igual lo bien que hable.

El modelo rellena los huecos que le dejes

Hay un principio que conviene interiorizar: un modelo de lenguaje inventa comportamiento para cualquier hueco que no le hayas definido. Si no le dices qué pasa cuando la hora ya está ocupada, se inventará una respuesta. Si no le dices qué hacer cuando el sistema no contesta, improvisará. Y la improvisación, con el dinero o la agenda de tus clientes de por medio, es exactamente lo que no quieres.

La solución no es un prompt más largo. Es un contrato claro para cada herramienta que el agente puede usar: una especificación de qué hace, qué necesita, qué devuelve y qué ocurre cuando algo sale mal. Sin huecos. Donde no hay hueco, no hay nada que inventar.

Qué incluye un buen contrato de herramienta

Un contrato completo cubre ocho apartados. Saltarse cualquiera de ellos es dejar un hueco.

1. Propósito en una frase

Qué hace la herramienta, en lenguaje llano. "Reservar una cita en la agenda del doctor para una fecha y hora concretas." Si no lo puedes decir en una frase, probablemente la herramienta hace demasiadas cosas y conviene partirla.

2. Entradas con validación

Cada dato que la herramienta necesita, con sus reglas de formato. El teléfono tiene que tener un formato válido; el identificador del paciente tiene que existir en el sistema. Rechazar las llamadas mal formadas antes de ejecutarlas evita fallos silenciosos que luego nadie sabe de dónde salieron. Y como muchos de esos datos son personales, conviene tener claro desde el contrato qué crea el agente y qué exige el RGPD.

3. Esquema de salida

La estructura exacta de la respuesta cuando todo va bien: identificador de confirmación, fecha y hora, estado. El agente tiene que saber con precisión qué recibe para poder decir la frase correcta al cliente. "Le confirmo su cita, el código es…" solo funciona si sabe dónde viene el código.

4. Tiempo de espera y reintentos

Cuánto espera el agente antes de dar la herramienta por fallida. Para un SMS de confirmación, por ejemplo: cinco segundos de espera y un reintento. Si el reintento también falla, se escala a una devolución de llamada humana. Sin un techo de tiempo, el agente se queda esperando y la persona, al teléfono, escuchando silencio.

5. Idempotencia (no negociable)

Este es el apartado que le faltaba a la clínica del principio. Toda herramienta que cambia algo —reservar, cobrar, dar de alta— tiene que impedir acciones duplicadas. Se hace generando un identificador único de la petición a partir de los datos de la llamada: si esa misma petición llega dos veces, la segunda devuelve el resultado de la primera en lugar de ejecutar la acción otra vez. La idempotencia no es opcional en nada que modifique datos. Es lo que separa "el sistema tardó y reintentamos" de "tres pacientes con la misma hora".

6. Mapa de errores con respuesta hablada

Cada error posible, traducido a una frase que el agente dice y a una acción siguiente. No "error 500": una respuesta humana. Por ejemplo:

• Sin disponibilidad → "Esa hora no la tengo libre, pero puedo ofrecerle el jueves a las 10 o el viernes a las 12. ¿Le encaja alguna?"
• Paciente no encontrado → "No localizo su ficha. ¿Me confirma su fecha de nacimiento?"
• La hora se acaba de ocupar → "Justo me la han cogido. La siguiente libre es a las 10:30. ¿Se la reservo?"
• El sistema de citas no responde → "Estoy teniendo problemas para acceder a la agenda. Permítame un momento y lo intento de nuevo."
• Datos de pago no válidos → se transfiere a una persona para gestionar el cobro.

Cada hueco de esta lista que dejes en blanco es una frase que el modelo se inventará en directo, delante de tu cliente. Y por eso cada error necesita su salida: a veces reintentar, a veces pasar la llamada a una persona con el contexto ya recogido.

7. Fallos parciales

Cuando una operación tiene varios pasos, hay que decidir qué se acepta que vaya bien y mal por separado. ¿Es válido que la cita se reserve pero el SMS de confirmación no salga? Casi siempre sí, con degradación elegante: "Le he reservado la cita; el mensaje de confirmación no ha salido, así que se lo envío por correo." Mejor eso que cancelarlo todo porque falló el último paso.

8. Pruebas

El contrato no está terminado hasta que se ha probado: el camino feliz, cada uno de los errores del mapa, la idempotencia (llamar dos veces con el mismo identificador y verificar que no hay duplicado), el comportamiento al agotarse el tiempo y las respuestas lentas. Si no lo has probado, no lo tienes; lo supones.

Tres equilibrios que vas a tener que decidir

Todo o nada frente a degradación elegante. Lo más limpio sería que, si falla un paso, se deshaga todo (la operación atómica). En la práctica, deshacer cambios entre varios sistemas suele ser inviable. Casi siempre es mejor avisar del estado parcial —"cita reservada, mensaje no enviado"— que no dar servicio.

Latencia frente a fiabilidad. Las herramientas que tardan —consultas complejas, comprobaciones de estado— gastan de tu presupuesto de un segundo. Ayuda lo asíncrono: lanzar la consulta, decir una frase puente ("déjeme que lo compruebo…") y seguir hablando mientras llega la respuesta. Y lo que se pueda precalcular o cachear, mejor que consultarlo en tiempo real en plena llamada.

Seguridad del reintento frente a experiencia. Reintentar protege de fallos pasajeros, pero si el reintento también tarda, alargas el silencio. La política sana: un reintento con un tiempo claro y, si falla, escalar, en lugar de reintentar sin fin mientras el cliente espera.

Prueba las herramientas antes que la conversación

Hay un orden que mucha gente invierte y paga caro: los contratos de las herramientas se prueban antes que la conversación. Si las herramientas fallan, probar la conversación no sirve de nada, porque no sabrás si el problema es lo que el agente dice o lo que el sistema hace por debajo. Primero verifica que cada herramienta se comporta como dice su contrato —incluidos todos los errores—. Solo entonces prueba cómo el agente habla del éxito y del fallo.

El contrato, punto por punto

Antes de dar por buena cualquier integración de tu agente, comprueba que su contrato responde a esto:

• ¿Está su propósito en una sola frase?
• ¿Están todas las entradas con sus reglas de validación?
• ¿Está definido el formato exacto de la respuesta correcta?
• ¿Tiene tiempo máximo de espera y política de reintento?
• Si cambia datos, ¿es idempotente? (esto, sí o sí)
• ¿Hay una frase hablada y una acción siguiente para cada error?
• ¿Está decidido qué pasa con los fallos parciales?
• ¿Se ha probado todo lo anterior, no solo el camino feliz?

La conversación es lo que el cliente oye. El contrato es lo que de verdad ocurre. Un agente que habla de maravilla sobre integraciones mal definidas no es un buen agente: es un problema con buena voz.