Por qué los agentes de IA necesitan pruebas antes de volver a intentarlo

Cómo evitar que una respuesta perdida provoque una acción duplicada

Un agente de soporte autorizado para emitir un reembolso envía la solicitud, pero pierde la conexión. El agente no recibe confirmación de que se haya completado correctamente e intenta enviar el reembolso de nuevo. Si la solicitud original se procesó correctamente, el segundo intento del agente podría generar un segundo reembolso.

Esto es puramente hipotético. El ejemplo representa un problema que no puede resolverse únicamente con la precisión del modelo. ¿Qué acciones debería llevar a cabo un agente si no puede determinar si su acción anterior modificó el estado del entorno?

Unite.AI ha explorado la fiabilidad de los agentes más allá de los modelos. En esos debates, los problemas de recuperación merecen tener sus propias reglas. Antes de volver a intentar una acción con consecuencias, el agente debería confirmar qué ocurrió o contar con una garantía válida que evite efectos duplicados.

Una respuesta que no llega no demuestra que la acción haya fallado

Que una respuesta no llegue no demuestra que una acción haya fallado. No indica si se produjo un error antes de la ejecución, si la acción se completó sin que se recibiera una confirmación o si el proceso sigue en curso.

Este es un problema habitual en los sistemas distribuidos, tal como describe Amazon. Amazon explica por qué los mecanismos de reintento necesitan salvaguardas específicas para evitar efectos secundarios repetidos. Los agentes incorporan una nueva entidad de toma de decisiones a la ruta de recuperación del sistema. Pueden tomar decisiones adicionales sobre cómo recuperarse de los errores.

Estas decisiones pueden modificar la forma de operar de una empresa. Por ejemplo, volver a intentar un reembolso por un importe distinto no es simplemente repetir la misma solicitud. Del mismo modo, elegir un segundo servicio de pago cuando el primero ha dejado de responder no es simplemente repetir la misma solicitud.

Los equipos deben distinguir entre autorizar la ejecución de una acción y autorizar la recuperación ante un resultado desconocido. La aprobación original no implica que sea seguro volver a ejecutar la acción.

Investigaciones recientes miden el riesgo

Un preprint de septiembre de 2026, «Where Does Exactly-Once Live?», presentó el banco de pruebas LIMBO y evaluó 25.930 episodios en nueve modelos. Sus servicios simulados se probaron con confirmaciones perdidas, procesamiento retrasado y entregas duplicadas.

De los 1.279 episodios en los que se generó un efecto duplicado en la prueba principal de los autores, los agentes informaron de que la tarea se había completado correctamente en el 90 % de los casos. Por lo tanto, un agente puede informar de que todo salió bien incluso cuando se ha producido un procesamiento incorrecto.

Estos resultados se basan en bancos de pruebas controlados y no permiten estimar las tasas de fallos en producción. Los servicios se simularon y varios análisis fueron exploratorios. Los equipos deben evaluar los resultados de las acciones de los agentes por separado de sus informes de ejecución satisfactoria.

El artículo también explica por qué comprobar el estado actual puede no ser suficiente. Una solicitud que todavía se está procesando puede surtir efecto después de la comprobación. Incluso una respuesta de estado vacía no significa que la solicitud no vaya a surtir efecto más adelante.

Los reintentos corresponden a la misma intención

Un servicio receptor dispone de un método para reconocer los intentos repetidos de una misma operación mediante una clave de idempotencia. Si se implementa correctamente, este método garantiza que los intentos repetidos no generen efectos adicionales. La clave de idempotencia debe mantenerse igual en todos los reintentos.

La documentación de la API de Stripe ofrece ejemplos tanto de los mecanismos como de las limitaciones de las claves de idempotencia. En la API v1, las claves pueden eliminarse transcurridas al menos 24 horas. Si se vuelve a utilizar una clave eliminada, se generará una nueva solicitud. Stripe también verifica que los parámetros proporcionados por quien realiza la solicitud coincidan con los de la solicitud inicial.

En la práctica, la idempotencia debe implementarse en la capa de integración, no solo en una instrucción. Antes de enviar una operación, registra la operación autorizada. Guarda su identificador, los parámetros exactos, la referencia del proveedor, si corresponde, y el estado de la operación.

En el caso de un reembolso, guarda el vínculo entre la aprobación y la transacción original, así como los identificadores de reembolso del proveedor que se devuelvan. Buscar cualquier reembolso por el mismo importe es una prueba menos convincente, porque dos solicitudes legítimas podrían tener el mismo importe. También podría haber un retraso entre la solicitud de reembolso y su aparición en los resultados de búsqueda. La solicitud original podría seguir en curso.

Cuando se reinicie un agente o un proceso de trabajo, la capa de ejecución debería conservar esa identidad. Debería rechazar toda solicitud modificada que se presente como si correspondiera a la misma operación. Ese cambio representa una acción nueva que, según las reglas del flujo de trabajo, requiere una nueva decisión de aprobación.

Las descripciones de las herramientas no bastan

Además de las descripciones de las herramientas, comprueba el contrato del servicio receptor para verificar si admite la idempotencia. Prueba su implementación para confirmar qué garantías se cumplen realmente.

Trata la incertidumbre como un estado operativo

Figura 1. Ruta propuesta de recuperación para acciones con consecuencias. Cada reintento también requiere una autorización vigente.

La finalización confirmada significa que el flujo de trabajo documentará el resultado y continuará sin repetir la acción. La confirmación de que la acción no se ejecutó permite intentarlo de nuevo solo si no queda ninguna solicitud original pendiente y la autorización sigue vigente.

Hay muchos otros aspectos que considerar cuando el resultado no está resuelto. Si existe una garantía válida respaldada por el proveedor contra los efectos duplicados, se puede permitir que se vuelva a intentar la solicitud original con la misma clave. De lo contrario, se deben suspender las escrituras y aclarar la situación mediante una consulta de estado, con el servicio de asistencia del proveedor o a través de un operador autorizado. Una comprobación no concluyente no es motivo suficiente para autorizar otro intento.

También puede estar justificado hacer una pausa cuando el proveedor documenta los límites de procesamiento y visibilidad. Sin esos límites, el mero paso del tiempo no confirmará que la acción no se haya ejecutado. Hay que definir quién se hace cargo de los casos que no se resuelven y cuándo debe revisarlos esa persona.

La recuperación ante un fallo puede requerir un proceso empresarial diferente

Si un reembolso se procesa correctamente, pero falla la notificación posterior al cliente, repetir todo el flujo de trabajo podría duplicar el reembolso. La recuperación debe centrarse en completar el paso pendiente y conservar pruebas del trabajo ya realizado.

Si se necesitan acciones correctivas para acciones completadas con anterioridad, Microsoft ofrece orientación sobre las transacciones de compensación. Cada aplicación determina la forma adecuada de compensar los errores. La compensación no necesariamente devuelve las cosas a su estado inicial y, además, puede fallar.

Además, cancelar una transacción puede generar un cargo. Corregir un mensaje no garantiza que nadie haya visto una versión anterior. Por lo tanto, toda actividad de recuperación debe limitar explícitamente lo que el agente puede deshacer, cambiar o comprometerse a hacer. Las decisiones que excedan esos límites deben remitirse a una persona con la autoridad necesaria.

Pruebe el segundo intento antes del despliegue

Elija una herramienta con consecuencias importantes y realice pruebas de recuperación deliberadas en un entorno de prueba. Después de una ejecución satisfactoria, descarte la respuesta a la solicitud original. Retrase la ejecución de la primera solicitud hasta después de consultar su estado. Durante la recuperación, reinicie el proceso de trabajo. Espere a que venza el período de retención de la clave antes de volver a intentarlo. Cambie un parámetro durante los intentos repetidos.

Evalúe los registros empresariales resultantes en lugar de confiar únicamente en las respuestas de las herramientas. Registre los efectos duplicados, las operaciones sin resolver, el trabajo omitido, el tiempo de recuperación y las intervenciones manuales adicionales. Calcule el costo por tarea completada correctamente usando los costos totales del flujo de trabajo, incluidas las reversiones de transacciones y las compensaciones para los clientes.

Además, pruebe una solicitud nueva y real, similar a la original. Asegúrese de que el sistema evite crear duplicados sin impedir que se realicen tareas nuevas. Evalúe por separado la prevención de duplicados y la finalización eventual de las tareas. De lo contrario, un agente que ponga fin a todas las tareas podría parecer seguro, aunque aporte poco o ningún valor.

La pregunta de evaluación debe formularse con claridad. ¿Pudo el sistema explicar lo siguiente:

• ¿Qué operación estaba autorizada?
• ¿Qué pruebas había para demostrar el resultado?
• ¿Por qué estaba permitido volver a intentarlo?

Un agente que hace una pausa debido a una incertidumbre sin resolver puede parecer menos eficaz durante las demostraciones. Sin embargo, en entornos de producción, hacer una pausa puede preservar la intención original del cliente. La persistencia útil implica que el sistema completa las tareas autorizadas sin ejecutarlas dos veces de forma inadvertida.