El patrón PRG para agentes de IA
Los agentes de IA se están topando con un problema antiguo. Es el mismo error que rompía los formularios web en los años 90.
En los viejos tiempos de la web, un usuario enviaba un formulario. Si pulsaba actualizar, el navegador volvía a enviar los datos. Esto significaba dos pedidos, dos cargos o dos correos electrónicos.
La solución fue el patrón Post/Redirect/Get (PRG).
La lógica es sencilla:
- El usuario envía una solicitud POST.
- El servidor procesa el trabajo.
- El servidor envía un redireccionamiento 302 a una nueva URL.
- El navegador sigue el redireccionamiento con una solicitud GET.
Ahora, al actualizar, solo se recarga la página de resultados. No se repite la acción.
Los agentes de IA han traído este error de vuelta a una nueva capa.
Cuando un agente llama a una herramienta para cobrar una tarjeta o crear un registro, las cosas salen mal. Ocurre una caída de red. Un contenedor se reinicia. Se activa un límite de tasa (rate limit). El agente no sabe si la última llamada funcionó. Por lo tanto, reintenta.
Sin una solución, el agente crea pedidos duplicados y cobra a clientes enfadados.
Debes aplicar el patrón PRG a tus pipelines de agentes utilizando claves de idempotencia.
La clave de idempotencia es tu redireccionamiento. Separa la acción del resultado.
Cómo implementarlo:
- Cada herramienta que muta debe aceptar una clave de idempotencia.
- Genera la clave antes del primer intento.
- Deriva la clave de la intención del usuario, no de una marca de tiempo.
- El servidor debe comprobar si ya ha visto la clave antes.
- Si la clave existe, devuelve el resultado almacenado en lugar de ejecutar la tarea de nuevo.
Para tareas largas, necesitas algo más que una simple clave. Necesitas checkpointing.
El checkpointing guarda el estado en cada paso. Si el agente falla a mitad de una tarea de veinte minutos, retoma desde donde se quedó. No empieza de cero.
Si solo puedes hacer una cosa, haz que cada llamada a una herramienta sea segura de ejecutar dos veces.
Construye tus agentes con estas cinco comprobaciones:
- ¿Acepta cada herramienta una clave de idempotencia?
- ¿Se basa la clave en la intención en lugar del tiempo?
- ¿Se reutiliza la clave en cada reintento?
- ¿Devuelve el servidor los resultados almacenados para claves duplicadas?
- ¿Se guardan los pasos intermedios para las tareas largas?
El patrón es el mismo. Solo ha cambiado la capa.