Tu agente le dice a una clienta que su cita del jueves está confirmada. El calendario nunca recibió la petición, porque en ese momento no respondía. La clienta se va tranquila, tu equipo no ve nada en la agenda y el jueves nadie la espera. Cuando una función que el agente llama falla, hay tres comportamientos posibles: reintenta, avisa o se inventa el resultado. Los dos primeros son aceptables si están bien diseñados; el tercero es el que hay que descartar desde el principio.
Una empresa grande cuenta con un equipo que vigila sus sistemas y recibe una alerta cuando algo se cae. Una pyme no suele tenerlo, así que la pregunta es quién se entera, y cuándo, cuando una pieza deja de contestar. Lo importante es que lo decidas tú antes de poner el agente a trabajar, no cuando ya ha pasado.
¿Qué ocurre cuando el calendario o el ERP no responde?
Cuando el calendario o el programa de gestión no responde, el agente puede hacer una de estas tres cosas, y conviene saber cuál hace el tuyo. Puede reintentar la operación un par de veces y, si no funciona, avisar. Puede avisar enseguida al cliente y a una persona de tu equipo de que la acción no se ha completado. O puede decir que todo está hecho aunque no lo esté, porque no se le ha enseñado a distinguir "hecho" de "no he recibido respuesta". Esta última es la peor, porque el error no se ve hasta que lo sufre un cliente.
Por eso, la regla de oro es sencilla: el agente solo debe dar algo por hecho cuando el sistema le haya confirmado que está hecho. Si no hay confirmación, dice la verdad: "no he podido guardar tu cita, una persona te lo confirmará".
Un ejemplo paso a paso: la cita que no se guardó
Imaginemos una clínica pequeña. Compara cómo termina el mismo fallo con dos diseños distintos:
| Paso | Diseño frágil | Diseño bien resuelto |
|---|---|---|
| La clienta pide cita | El agente propone un hueco | Igual |
| El calendario no responde | El agente no distingue el fallo y sigue | El agente detecta que no hay confirmación |
| Respuesta a la clienta | "Cita confirmada" | "No he podido reservarla ahora mismo; te lo confirmamos en cuanto podamos" |
| Aviso interno | Ninguno | Queda en una lista de pendientes y llega un aviso a una persona |
| Resultado | La clienta aparece el jueves y no hay hueco | Una persona resuelve la cita antes de que sea un problema |
La diferencia no está en la tecnología sino en haber decidido, de antemano, qué debe pasar cuando algo no sale.
¿Quién nota el fallo y cuándo?
Debería notarlo primero el propio sistema, que deja constancia del error, y después una persona concreta de tu equipo, no el cliente. Sin ese diseño, el orden suele ser el contrario: el primero en enterarse es el cliente, el segundo es el empleado que recibe la queja y el último, tú. Los fallos que nadie ve son los más caros, porque se repiten una y otra vez sin que nadie los corrija.
Para que lo note el sistema primero, pide tres cosas:
- Un registro de errores. Cada vez que una función falla, queda anotado qué se intentó, cuándo y con qué respuesta.
- Un aviso a una persona. Un correo o un mensaje a quien corresponda, con lo que ha pasado en palabras comprensibles.
- Una lista de pendientes. Todo lo que el agente no pudo cerrar queda ahí, para que alguien lo termine a mano.
Reintentar sí, pero con cabeza
Reintentar tiene sentido cuando el fallo es pasajero, como una conexión que tarda. Pero hay acciones que no conviene repetir sin más. Si el agente intenta emitir un abono, no recibe respuesta y repite la orden, puede que se emitan dos. Por eso, en las operaciones que tocan dinero o envían documentos, el sistema debe poder comprobar si la acción ya se hizo antes de repetirla. Es una pregunta legítima para el proveedor: "si reintenta, ¿cómo evita duplicar una acción?".
Los reintentos también deben tener un límite. Un agente que insiste sin parar puede bloquear una cola o saturar un sistema que ya va justo. Mejor un par de intentos y, si no sale, avisar a una persona.
La pregunta clave que debes hacer a tu proveedor
Hay una pregunta que resume todo lo anterior, y conviene que la hagas por escrito: "Si el calendario, el ERP o el sistema de pedidos no responde cuando el agente intenta guardar algo, ¿qué le dice al cliente, qué queda registrado y quién recibe el aviso?"
La respuesta debería incluir:
- Qué mensaje recibe el cliente y que nunca sea una confirmación falsa.
- Dónde queda anotado el fallo y cuánto tiempo se conserva.
- Quién recibe el aviso, por qué canal y cómo se asegura de que alguien lo atiende.
- Cómo se retoman las operaciones pendientes cuando el sistema vuelve a funcionar.
Si la respuesta es vaga ("el agente es muy robusto"), insiste. Un buen proveedor puede enseñarte un ejemplo real de un fallo simulado, y es razonable que lo pruebes tú antes de dar el visto bueno. Te lo explicamos mejor en prueba de estrés para un chatbot de atención al cliente.
Qué hace el agente y qué sigue haciendo una persona
El agente detecta que una función no ha respondido, informa con honestidad al cliente, reintenta con límite y deja anotado el fallo. Una persona recibe el aviso, decide cómo se resuelve el caso del cliente y revisa periódicamente los registros para detectar si el mismo fallo se repite, porque eso suele indicar un problema de fondo en la conexión. Y las decisiones sobre dinero o documentos fiscales de un caso afectado las toma quien corresponda en tu empresa, con tu gestor si hace falta.
Qué cuidar
- Datos personales en los registros. Los avisos y los registros de error pueden incluir nombres o teléfonos. Limita quién los ve y cuánto tiempo se guardan; el detalle, con tu asesor de protección de datos.
- Fallos silenciosos. Pide una revisión periódica, aunque no haya avisos: no recibir alertas no demuestra que todo vaya bien.
- Pruebas de fallo. Antes del lanzamiento, desconectar a propósito un sistema para ver cómo reacciona el agente es la mejor forma de comprobarlo.
- Qué función es crítica. Hay funciones cuyo fallo es una molestia y otras cuyo fallo es un riesgo. Si quieres ver ejemplos, consulta ejemplos de function calling en una pyme.
Conclusión
Cuando falla una función del agente, lo importante no es que falle, sino qué hace después: reintentar con límite, avisar al cliente con honestidad y dejar constancia para que una persona lo resuelva. Lo inaceptable es que dé por hecho algo que no ha ocurrido. La pregunta al proveedor es una sola: qué le dice al cliente, qué queda registrado y quién recibe el aviso.
En MG Solutions construimos agentes de IA específicos para cada empresa, adaptados a tu forma de trabajar y a tus herramientas, no una plantilla genérica. Definimos contigo qué hace el agente ante cada fallo y a quién avisa.
Si quieres ver cómo encajaría en tu empresa, escríbenos y lo hablamos.