Cuando falla una herramienta: cómo evitar que un agente repita una acción

El problema: una acción puede ocurrir sin que llegue su confirmación

Un agente que utiliza herramientas puede iniciar una operación en otro sistema y perder la conexión antes de recibir una respuesta clara. La tarea queda entonces en una situación ambigua: el agente no sabe si el sistema de destino aplicó el cambio, pero la falta de confirmación tampoco demuestra que no lo aplicara. Volver a ejecutar la misma acción sin comprobar el estado puede crear un duplicado o ampliar el impacto.

Este problema es distinto de volver a generar una respuesta. En una conversación, una repetición puede producir texto diferente; cuando una herramienta modifica un registro, reserva una cita o cambia un archivo, la repetición puede producir un segundo efecto externo. Por eso, el procedimiento de recuperación debe empezar por averiguar qué ocurrió, no por repetir automáticamente la instrucción original.

La guía propone una disciplina operativa, no una garantía de que cualquier sistema permita recuperarse. La capacidad de verificar, detener o compensar depende de las herramientas concretas y de las funciones que documenten. Si no se puede observar el estado de destino, el agente debe tratar la incertidumbre como una condición para pausar o escalar, no como permiso para suponer.

Delimitar el flujo antes de diseñar la recuperación

Describe la tarea como una secuencia de pasos concretos y señala qué herramientas intervienen. Para cada paso, anota si solo lee información, si escribe o modifica un estado, o si puede producir un efecto externo que sea difícil de revertir. Esta clasificación permite concentrar controles en los pasos donde una repetición podría tener consecuencias.

No basta con clasificar una herramienta por nombre. Una misma integración puede ofrecer una consulta y una operación de escritura. Tampoco basta con describir la intención general del agente: «gestionar una cita» puede incluir buscar disponibilidad, crear una reserva y enviar una notificación. Cada operación puede tener un estado distinto y requerir una decisión de recuperación diferente.

Identifica también qué observación permite considerar completo cada paso. Para actualizar un registro, por ejemplo, puede ser necesario volver a leer el registro y comprobar los campos relevantes. Para una reserva, puede hacer falta consultar si existe una cita con los datos esperados. Para modificar código, puede comprobarse el contenido del archivo o el estado del cambio. Estos son patrones de diseño: hay que adaptarlos a las capacidades reales de cada sistema.

Antes de permitir una escritura, define el alcance: qué entidad puede modificar el agente, qué datos puede cambiar y qué acciones quedan fuera de sus permisos. Los permisos limitan el daño potencial, pero no prueban que una acción anterior haya tenido éxito ni hacen segura una repetición. La selección de herramientas debe mantener esa separación entre autorización y conocimiento del estado.

Clasificar el estado antes de decidir

Tras un fallo, registra la última observación fiable y clasifica el paso interrumpido. Una taxonomía práctica distingue cuatro estados: la acción no se inició; el resultado está confirmado; el resultado es incierto; o la tarea quedó parcialmente completada. La clasificación debe basarse en evidencia disponible, no en la explicación que el agente prefiera dar.

«No iniciada» significa que hay evidencia suficiente de que el paso no se envió o no empezó. «Confirmada» significa que una respuesta o una consulta posterior permite verificar el resultado esperado. «Incierta» significa que falta evidencia para decidir entre ejecución y no ejecución. «Parcial» indica que algunos pasos o efectos se completaron, mientras que otros siguen pendientes. En caso de duda entre dos categorías, conserva la más prudente y evita convertir incertidumbre en confirmación.

La diferencia importa porque la acción adecuada cambia. Si el paso no empezó, puede ser posible iniciarlo, sujeto a permisos y reglas del flujo. Si está confirmado, no debe repetirse solo para obtener una respuesta más clara. Si es incierto, primero se consulta el destino; si no existe una consulta fiable, se detiene o se escala. Si el trabajo está parcialmente completado, se reanuda únicamente desde un estado comprobado, teniendo en cuenta los efectos que ya ocurrieron.

El estado del agente no debe confundirse con el estado del sistema externo. Un checkpoint puede guardar qué pasos intentó el flujo o qué respuesta recibió, pero esa información puede quedar desactualizada si otro proceso modifica el destino o si la confirmación se perdió. El checkpoint ayuda a recuperar contexto; no demuestra por sí mismo cuál es el estado vigente.

Antes de repetir, consulta el destino y busca señales de duplicado

La primera pregunta operativa no es «¿puedo llamar otra vez a la herramienta?», sino «¿qué puedo observar ahora en el sistema afectado?». Si hay una consulta autorizada, busca el objeto o cambio relacionado con la tarea mediante los datos que lo identifiquen. Comprueba que coincidan los atributos pertinentes y que no haya ya un resultado equivalente. Evita depender de una sola señal si esta no distingue la operación actual de otras parecidas.

Una solicitud puede tener un identificador de operación o una referencia propia de la tarea. Si el sistema documenta una forma de consultar la operación o reconocer solicitudes duplicadas, sigue ese mecanismo tal como está documentado. No supongas que todas las herramientas aceptan una clave de idempotencia, que un identificador impide efectos repetidos o que un resultado con el mismo texto corresponde necesariamente a la misma acción.

La detección de duplicados exige criterios claros. Para una actualización de registro, compara el identificador del registro y los campos que se pretendían cambiar. Para una cita, revisa los datos que distinguen esa reserva y su estado actual. Para un cambio de código, inspecciona el archivo o el estado del cambio antes de aplicar otra modificación. Son ejemplos de comprobación, no descripciones de funciones garantizadas de un proveedor.

Si la consulta de estado no está disponible, devuelve información incompleta o no permite distinguir una operación previa, la incertidumbre continúa. En ese caso, define una condición de parada. La falta de una respuesta verificable no debe convertirse en una suposición favorable, sobre todo cuando una segunda ejecución podría crear un efecto adicional.

Elegir entre continuar, compensar, detenerse o escalar

Continúa cuando el estado anterior sea suficientemente conocido, el paso pendiente esté dentro del alcance autorizado y exista una forma de verificar el resultado. Reanudar significa avanzar desde el último estado comprobado, no reproducir toda la secuencia desde el principio. Si el flujo consta de varios pasos, identifica cuáles están confirmados y cuáles todavía no empezaron para evitar rehacer trabajo que ya produjo efectos.

Una compensación intenta corregir un efecto confirmado mediante una acción distinta. No siempre es posible, y no equivale necesariamente a restaurar exactamente la situación inicial. Antes de diseñarla, comprueba que el sistema documenta esa operación, que la cuenta tiene permiso para ejecutarla y que el cambio no afectará a un estado posterior. Si no puedes confirmar esos requisitos, no la presentes como una reversión garantizada.

Detenerse es una decisión válida cuando la siguiente acción puede agravar una situación incierta, excede el alcance autorizado o carece de verificación suficiente. Escalar a una persona resulta apropiado cuando hace falta interpretar evidencia ambigua, aprobar una acción de mayor impacto, valorar una compensación o decidir cómo tratar un cambio que no se puede deshacer con seguridad. La pausa debe conservar el contexto mínimo que permita revisar el caso.

Define de antemano qué condiciones requieren intervención humana. Por ejemplo: resultado de escritura incierto sin consulta de destino; operación con consecuencias relevantes cuya repetición pueda duplicar un efecto; compensación no documentada; permiso insuficiente para verificar; o discrepancia entre el estado almacenado en el flujo y el sistema de destino. Ajusta estos umbrales al impacto y a las obligaciones del entorno, en vez de usar una regla única para cualquier acción.

Ejemplos aplicados: reserva y modificación de código

En una reserva de cita, una respuesta perdida después de enviar la solicitud deja abierta la posibilidad de que exista ya una cita. El agente debe consultar el estado de la reserva con las capacidades reales disponibles y comprobar si la cita esperada aparece. Si encuentra un resultado coincidente, no debe crear otra reserva para resolver la falta de confirmación. Si no puede distinguir una operación ya realizada de una aún pendiente, debe detener el intento automático y pedir revisión según la política del servicio.

La comprobación también debe tener en cuenta que el estado puede cambiar entre la consulta y la acción siguiente. Por eso, el flujo debe evitar tratar una observación antigua como garantía indefinida. Si la herramienta ofrece una referencia de operación o una consulta de estado documentada, úsala; si no, limita las conclusiones a lo que realmente se pudo observar. No afirmes al usuario que la reserva está confirmada si la evidencia solo demuestra que el agente intentó solicitarla.

Al modificar código, el riesgo no se limita a repetir una escritura sobre el mismo archivo. El contenido puede haber cambiado desde el checkpoint, o una parte de la tarea puede haberse aplicado mientras otra quedó pendiente. Antes de volver a modificarlo, inspecciona el estado actual y compara el cambio esperado con el resultado observable. Si la modificación ya está presente, evita aplicarla de nuevo a ciegas. Si el estado difiere o no puede reconstruirse, detén el flujo para revisar qué debe conservarse y qué puede corregirse.

En los tres ejemplos, el agente debe comunicar con precisión el resultado: intento realizado, efecto comprobado, resultado incierto o intervención requerida. La descripción del proceso no debe convertir una llamada emitida en una tarea completada.

Guardar contexto útil sin confundirlo con el estado vigente

Para reanudar una tarea no hace falta conservar indiscriminadamente toda la conversación. Guarda el estado operativo que permita reconocer la tarea y reconstruir sus decisiones: identificador o referencia de la tarea si existe; paso actual; herramienta y operación invocadas; última respuesta observada; estado clasificado; comprobaciones realizadas y su momento; efectos confirmados; y motivo de cualquier pausa o escalado. Registra también qué queda pendiente y qué límites de autorización se aplican.

Evita guardar datos sensibles que no sean necesarios para la recuperación. Define quién puede consultar el registro, cuánto tiempo se conserva y cómo se elimina o protege según las reglas del entorno. La duración no debe inventarse como un valor universal: depende de los requisitos de privacidad, auditoría y operación aplicables. Si el registro contiene datos personales o detalles de sistemas, limita su alcance y acceso.

La memoria conversacional y un checkpoint de tarea cumplen funciones distintas. La primera puede ayudar a contextualizar lo que el usuario pidió; el segundo debería representar el estado operativo observado por el flujo. Ninguno sustituye una consulta al sistema de destino cuando la tarea depende de un efecto externo que pudo cambiar. Trata la memoria como una pista para orientar la recuperación, no como evidencia suficiente de que el mundo externo sigue igual.

Incluye marcas temporales o el orden de las observaciones cuando sean necesarias para interpretar el registro. Si otra persona o proceso puede modificar el sistema, una lectura anterior podría haber quedado obsoleta. Al reanudar una operación sensible, vuelve a comprobar los datos relevantes en vez de asumir que el checkpoint mantiene vigencia.

Permisos y autonomía: limitar lo que puede hacer el paso de recuperación

Diseña los permisos para que cada operación tenga el alcance mínimo necesario. Si el agente solo necesita comprobar un resultado, no presupongas que deba poder modificar otros registros o cancelar operaciones. Si una compensación requiere un permiso distinto, sepárala de la consulta y define qué condición autoriza su uso. Esto hace visible la diferencia entre observar, actuar y corregir.

La recuperación no debe ampliar la autonomía por el mero hecho de que el flujo haya fallado. Un agente que tenía permiso para efectuar un cambio inicial no adquiere automáticamente permiso para ejecutar acciones adicionales, revertirlo o modificar objetos relacionados. Especifica qué decisiones son automáticas, cuáles requieren aprobación y qué información debe presentarse a la persona para que pueda decidir.

La aprobación humana ha de referirse a una acción concreta y a su evidencia. En lugar de pedir una autorización genérica para «resolver el problema», explica qué estado se observó, qué no se pudo confirmar, qué acción se propone y qué efectos podría tener. Si falta información esencial, el siguiente paso debe ser obtenerla o detenerse, no solicitar una aprobación que oculte la incertidumbre.

Los permisos reducen el conjunto de acciones posibles; no resuelven por sí solos los fallos parciales. Mantén separadas las barreras de alcance, los mecanismos de consulta y las reglas de recuperación. Un diseño fiable necesita los tres elementos allí donde la tarea pueda producir cambios externos.

Probar fallos reproducibles antes del despliegue

Las pruebas deben simular no solo errores de herramienta, sino también la separación entre ejecución y confirmación. Un caso importante es que el sistema de destino aplique un cambio y que el agente no reciba la respuesta. La prueba verifica que el flujo consulte el destino o se detenga, en vez de repetir automáticamente. Si el entorno de prueba no puede reproducir ese comportamiento, documenta la limitación y comprueba al menos la política de incertidumbre con respuestas ambiguas controladas.

Incluye confirmaciones tardías. Por ejemplo, el agente puede pausar y empezar una comprobación mientras llega después la respuesta de la operación original. Verifica que esa respuesta tardía actualice el estado de forma coherente y no dispare una segunda ejecución. Prueba también el caso opuesto: la primera operación no se realizó y el flujo obtiene evidencia suficiente para iniciar el paso pendiente según sus reglas.

Añade escenarios con duplicados, estado parcial, consulta de destino no disponible, permiso insuficiente y compensación no documentada. Para cada uno, define el resultado esperado antes de ejecutar la prueba: qué acciones puede realizar el agente, cuáles debe evitar, qué debe registrar y cuándo debe escalar. Una prueba que solo verifica que el agente responde no demuestra que la recuperación sea segura.

Usa resultados verificables. Cuenta cuántas operaciones de escritura se ejecutaron, comprueba el estado final en el sistema de destino, identifica duplicados y revisa si se produjeron efectos fuera del alcance autorizado. Evalúa por separado la tarea original y la recuperación: el hecho de que el usuario obtenga finalmente un resultado no basta para demostrar que el flujo evitó una repetición o respetó sus límites.

Repite las pruebas cuando cambien las herramientas, los permisos, la política de reanudación o el formato de los checkpoints. Registra las versiones y condiciones relevantes para que los resultados puedan reproducirse. No interpretes una prueba aprobada como garantía frente a cualquier fallo futuro: demuestra el comportamiento observado en los escenarios definidos.

Evaluar el flujo y preparar el despliegue

Evalúa la recuperación con varias medidas, no con una sola etiqueta de éxito. Revisa cuántas veces se repitió una escritura, cuántos resultados finales se comprobaron, cuántos casos quedaron correctamente detenidos y cuántas acciones excedieron los permisos. Añade una revisión de los escalados para saber si contenían suficiente contexto y si se activaron ante las condiciones previstas.

Interpreta las métricas junto con los casos de prueba y el impacto posible. Una tasa baja de repetición no demuestra que el sistema sea seguro si también dejó tareas ambiguas sin detectar. Un estado final correcto tampoco basta si se alcanzó mediante una acción duplicada o una compensación no autorizada. Define de antemano qué resultados son aceptables y qué fallos bloquean el despliegue.

Antes de habilitar acciones de mayor impacto, ensaya el procedimiento con operaciones de bajo riesgo o un entorno de prueba adecuado. Confirma que las consultas de estado funcionan, que los permisos son suficientes para verificar pero no excesivos para actuar, que los registros permiten reconstruir lo ocurrido y que las pausas llegan a una persona capaz de decidir. Si alguna dependencia no está disponible, limita el alcance de la automatización en vez de asumir que el agente podrá resolverla.

Las fuentes disponibles incluyen documentación de solución de problemas de herramientas y orientación general sobre gestión de incidentes y recuperación ante desastres. No establecen por sí solas cómo se comporta una integración concreta ante una respuesta perdida, si permite detectar duplicados o si una operación puede revertirse. Esos puntos deben verificarse para cada sistema antes de convertir una recomendación de diseño en una instrucción operativa.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.