Agente de soporte en producción: Temporal, sagas y circuit breaker protegen los reembolsos de los fallos

Un cliente escribe: «El paquete no ha llegado, devuélvanme el dinero». El agente que responda a eso se puede escribir en una tarde: un bucle, tres herramientas, y en la demo todo funciona. Pero luego el proceso se reinicia en mitad de un reembolso, el proveedor del modelo se cae durante media hora y el cliente pulsa «enviar» dos veces. Resulta que el agente es solo una pequeña parte del sistema. La parte final de la serie en Habr construye ese sistema paso a paso, y su principal valor es que cada componente aparece como respuesta a una avería concreta.

De un solo archivo a API, worker y Temporal

La versión inicial guarda el historial de la conversación en la memoria del proceso. Un reinicio borra todas las conversaciones, los clientes se atienden de uno en uno, y si el proceso se cae entre la llamada a refund_payment y la respuesta, nadie sabe si el dinero se devolvió o no.

Primer paso: separar el script en una API y un worker. La API recibe el mensaje, lo escribe en la base de datos y responde al chat de inmediato. No llama al modelo, así que responde en milisegundos. El bucle del agente vive en workers independientes, que se pueden añadir según la carga. El historial ahora está en la base de datos y sobrevive a los reinicios.

Pero el worker aún puede caerse a mitad de una consulta. Repetir el reembolso es peligroso: se puede pagar dos veces. No repetirlo también es malo: se puede no pagar nunca. Aquí entra Temporal: registra cada paso en un journal y otro worker continúa desde el mismo punto, sin volver a ejecutar los pasos ya completados. El bucle del agente vive en un workflow, y las llamadas al modelo y a las herramientas pasan a ser activities.

Dos aclaraciones importantes. Temporal tiene su propia base de datos y no es el lugar para guardar datos de negocio de los clientes: el journal de una ejecución está limitado a 51 200 eventos o 50 MB. Los workers con su código los ejecuta usted mismo; el servicio de Temporal no los ejecuta. Y el Workflow ID lo define usted: use el id de la conversación y un reenvío no creará un duplicado. Eso sí, no ponga datos personales en el ID, porque es visible en la interfaz y en los logs.

Un reintento no es un circuit breaker

Cuando el proveedor del modelo está caído media hora, Temporal reintenta la activity con toda fidelidad. Cien workers y mil consultas abiertas golpean a coro una API caída, y cuando esta se recupera, se le viene encima toda la cola.

El reintento está pensado para un fallo que pasa en segundos. Para una caída prolongada hace falta un circuit breaker. Cuenta los fallos, se abre al superar un umbral y devuelve el error de inmediato, sin llamar al servicio; pasado un tiempo, deja pasar una llamada de prueba. El estado del interruptor debe ser común a todos los workers; de lo contrario, cada uno tendrá que descubrir por su cuenta que el proveedor se ha caído. Por eso su lugar está en la pasarela de LLM, entre los workers y los proveedores. LiteLLM, por ejemplo, saca un modelo de la rotación tras una serie de fallos, cambia a uno de reserva y guarda el estado en Redis.

Consejo práctico del autor: que la activity distinga dos tipos de error. El temporal lo reintenta la política de Temporal. El error «interruptor abierto» no debe reintentarse: el propio workflow decide si pasar a un modelo de reserva, esperar o derivar la consulta a un operador. Los mismos interruptores se colocan delante del servicio de envíos y de la pasarela de pago.

Saga, operador y router

Un reembolso afecta a tres sistemas sin una transacción común: la etiqueta en el servicio de envíos, el dinero en la pasarela de pago, y la notificación al cliente junto con la actualización del pedido. Esto es una saga: cada paso tiene su compensación. El concepto clave es el punto de no retorno (pivot transaction). Antes de devolver el dinero, los pasos se pueden deshacer; después, el correo al cliente y la actualización del pedido deben completarse, cuantos reintentos hagan falta. Cada acción recibe una clave de idempotencia, por ejemplo el id de la decisión, y la pasarela de pago no cobrará el dinero de nuevo.

El modelo no debe tramitar sumas grandes. El workflow muestra la decisión en la consola del operador y espera una señal. La espera queda registrada en el journal y no ocupa un worker, de modo que el operador puede responder una hora después.

El último paso afecta al coste. No toda consulta requiere un bucle agéntico completo. Un router con un modelo pequeño envía las FAQ a una sola llamada, la pregunta «dónde está mi pedido» a una cadena predefinida, y solo el reembolso en disputa llega al agente. El principio es sencillo: elegir el nivel de complejidad más bajo que resuelva la tarea de forma fiable.

Qué hacer con todo esto

No conviene construir todo el esquema de golpe. El autor aconseja expresamente añadir un componente cuando aparezca el problema que cura. Si atiende a un cliente cada vez y no hay dinero en juego, basta con la base de datos. En cuanto aparecen efectos secundarios como los pagos, hacen falta idempotencia y durable execution. En cuanto aparece la dependencia de un proveedor externo, hace falta un interruptor común.

También hay limitaciones. El código del artículo es pseudocódigo. La afirmación de que el agente web de Codex funciona sobre Temporal procede del propio proveedor, y el autor no encontró confirmación independiente. Aun así, como mapa de los fallos típicos de un sistema agéntico, el texto resulta útil para cualquiera que lance un agente a producción. Empiece por preguntarse qué pasaría si el proceso se cae justo después de la llamada más arriesgada.