Imagina un agente encargado de procesar un reembolso parcial que recibe la aprobación e intenta enviar la solicitud a un sistema de pagos. En medio de este proceso, el agente falla. ¿Ha llegado la solicitud? ¿Se completó el reembolso? ¿O no se procesó en absoluto? Cuando otro agente toma el relevo, encuentra un registro que indica que la operación fue enviada pero sin resultado registrado, lo que plantea un grave problema de ambigüedad.
Este desafío no es exclusivo de los agentes inteligentes. Cualquier sistema distribuido que falle en mitad de una operación se enfrenta a obstáculos similares. Sin embargo, los agentes tienen una complejidad añadida: no solo siguen un flujo predefinido, sino que razonan de manera autónoma. Ante un mismo pedido sin resultado previo, un agente de reemplazo podría diseñar un plan distinto, emplear parámetros diferentes o incluso iniciar un nuevo reembolso, en lugar de continuar con el ya aprobado.
Esto podría provocar que el cliente reciba un reembolso doble si el primero se había ejecutado correctamente, situación que puede pasar desapercibida si queda saldo suficiente para cubrir ambos pagos. El principio clave es claro: un agente sustituto debe continuar la operación original, no reinterpretarla. 
La operación debe sobrevivir al agente
Todo lo que reside en la memoria del agente o en su contexto temporal de razonamiento se considera efímero y prescindible. Sin embargo, la operación comercial, con su aprobación, parámetros y estado actual, debe conservarse de manera firme. Mientras un agente pueda mantener el estado útil durante su ejecución, no debe depender que ese proceso original permanezca activo indefinidamente.
Por ello, antes de enviar una petición de reembolso, el sistema guarda un registro durable de la operación en un almacén transaccional. Este registro incluye el importe aprobado, la autorización, una clave de idempotencia para evitar repeticiones inadvertidas, el identificador de la operación y su estado.
El estado de la operación evoluciona de creado a enviado, y finalmente a confirmado o fallido según la respuesta del proveedor de pagos. Si el agente falla, el nuevo agente puede recuperar este registro y los identificadores de correlación. Un estado «enviado» sin resultado indica que el proceso fue iniciado pero no finalizado, evitando así la confusión de iniciar una nueva operación desde cero.
Este registro duradero no sólo sirve como contexto para el agente de reemplazo, sino que también es exigido por la capa de despacho que valida cada solicitud externa contra los registros aprobados. Así, aunque el agente proponga una acción, sólo se permiten operaciones autorizadas con sus parámetros originales. La inteligencia artificial no puede redefinir lo aprobado inicialmente.
Para gestionar todo este flujo, se utiliza la base de datos ClickHouse Managed Postgres para almacenar los datos comerciales y de operación. Además, registros detallados de telemetría y trazas de agente se replican con herramientas como ClickStack y Langfuse, que comparten backend en ClickHouse. Esto permite una consulta unificada, facilitando la identificación rápida de la relación entre el agente, la operación y cualquier fallo en la comunicación con el proveedor externo.
Reiniciar la ejecución no significa continuar de forma segura
Frameworks de ejecución duradera como LangGraph o Temporal ofrecen capacidades para registrar el progreso y reanudar tareas tras fallos. Sin embargo, recomiendan que los efectos secundarios sean idempotentes, ya que no pueden garantizar que una acción iniciada pero no confirmada externamente no se haya completado.
En concreto, la clave de idempotencia almacenada en el registro durable conecta el agente sustituto con la petición original, permitiendo que el proveedor de pagos reconozca intentos repetidos como la misma operación y no como duplicados. Este patrón, formalizado por AWS Builders’ Library, es fundamental para evitar inconsistencias.
No obstante, reintentar una operación puede no ser seguro si el resultado es incierto. Por ejemplo, Stripe reconoce que una respuesta de error 500 en un intento de mutación puede haber generado efectos externos, pero no confirmados. En estas situaciones, el agente de reemplazo debe contar con evidencias para investigar antes de actuar.
Herramientas como Langfuse y ClickStack permiten acceder a registros detallados y trazas del agente anterior, incluyendo las solicitudes enviadas, errores de conexión y contexto operativo, proporcionando pistas para diagnosticar qué ocurrió exactamente y cuándo. Sin embargo, la confirmación final siempre reside en el proveedor externo, siendo la fuente de verdad para el estado de la operación.
Seguir el trabajo, no empezar de nuevo
Con el registro duradero y las evidencias en mano, el agente reemplazo debe seguir un protocolo de recuperación definido que no se base en su propio juicio. Si el proveedor confirma que el reembolso se realizó, el agente registra la conclusión y finaliza. Si está pendiente, espera para evitar duplicidades. Si el reembolso falló sin efecto externo, puede intentar un nuevo envío tras verificar condiciones previas. En caso de incertidumbre, la mejor decisión es escalar la incidencia, no asumir resultados.
Además, el agente debe verificar que el contexto actual no haya cambiado: el saldo disponible, la intervención humana, el estado de la cuenta o la validez de la autorización. La aprobación almacenada representa evidencia histórica, pero no concede autoridad automática para actuar.
Finalmente, la clave en la ingeniería de sistemas con agentes IA es que el trabajo o la operación sean duraderos y coherentes, independientemente de que los agentes que ejecutan las tareas sean temporales y puedan ser reemplazados en cualquier momento.
