Cómo gobernar un agente persistente con leases, checkpoints y recuperación idempotente

Paso 1 — Convierte cada ejecución persistente en un objeto con contrato propio. Crea un run con owner, objetivo, fecha de inicio, deadline, presupuesto, herramientas autorizadas y outcome esperado. No uses la conversación como única fuente de estado. El run debe poder sobrevivir a que la interfaz se cierre y, al mismo tiempo, ser comprensible sin releer cientos de mensajes. Guarda referencias a artefactos y decisiones, pero evita copiar secretos innecesarios. El contrato inicial también define qué condiciones obligan a detenerse: falta de datos, presupuesto agotado, tool fuera de scope o verifier fallido. Un agente persistente debe saber exactamente qué significa continuar y qué significa pedir intervención.

Paso 2 — Separa memoria de autoridad mediante leases temporales. Asigna a las capabilities sensibles una autorización con expiración, límites y objetos concretos. La memoria puede conservar contexto por más tiempo, pero el permiso para enviar, publicar, desplegar o modificar sistemas debe caducar. Define una política de renovación: automática para acciones de bajo riesgo y explícita para efectos más sensibles. Registra quién emitió el lease, qué scope contiene y qué run lo está usando. Cuando expira, el agente puede seguir analizando o preparando borradores, pero no ejecutar la mutación. Este patrón evita que una tarea olvidada mantenga privilegios indefinidos solo porque su proceso sigue vivo en background.

Paso 3 — Diseña checkpoints semánticos y no simples heartbeats. Cada cierto número de pasos o minutos, el agente debe producir un checkpoint que indique subobjetivo completado, evidencia, gasto acumulado, bloqueos y siguiente acción. Un heartbeat binario solo dice que el proceso existe; no prueba progreso. Define thresholds: si no hay avance material en dos checkpoints, reducir recursos, pausar o pedir revisión. Incluye un contador de retries por herramienta y una causa normalizada de fallo. Así puedes distinguir una investigación legítimamente larga de un loop. El checkpoint también permite mostrar al usuario una vista compacta de lo que ocurrió mientras estuvo ausente, sin exponer ruido interno.

Paso 4 — Ata cada aprobación a efectos y condiciones explícitas. No guardes una frase como “sí, hazlo” y la reutilices indefinidamente. Crea un approval object que contenga action types, resources, límites, expiración y referencia al estado que el usuario revisó. Si cambian presupuesto, destinatarios o contenido, la aprobación puede quedar inválida. Antes de una acción sensible, la policy compara el intento contra el approval vigente. Si coincide, continúa; si no, prepara el trabajo y espera. Esto permite que el agente opere rápido dentro de una frontera clara y evita pedir confirmación por cada paso irrelevante. La aprobación se vuelve una capability temporal, no una interpretación lingüística repetida.

Paso 5 — Reconciliación primero, retry después. Después de un crash, timeout o reinicio, vuelve a leer los sistemas destino antes de repetir una mutación. Usa runKey, externalId o hash para detectar si el efecto ya existe. Si existe y coincide, registra éxito y continúa; si existe distinto, abre conflicto; si no existe, decide si el retry sigue siendo válido según lease y deadline. Prueba esta lógica de forma deliberada cortando ejecuciones después de writes. Un background agent confiable debe recuperarse sin duplicar emails, publicaciones, archivos o transacciones. La resiliencia no consiste en repetir más veces; consiste en saber qué ocurrió antes de volver a actuar.

Paso 6 — Emite un receipt y libera autoridad al terminar. Cuando el verifier confirma el outcome, genera un receipt con runId, acciones externas, IDs, costo, duración, approvals utilizados, excepciones y estado final. Luego revoca o deja expirar los leases que ya no hacen falta. La memoria puede conservar el resumen y los artefactos, pero el run pasa a completed y no puede reactivarse silenciosamente. Si quedan notificaciones auxiliares, trátalas como fases separadas. En Goatify, esta guía puede convertirse en el estándar de Persistent Agent Governance: delegación larga con autoridad corta, evidencia continua y recuperación idempotente. La autonomía se vuelve más útil porque tiene una frontera operacional visible.