Definición de un contrato de ejecución para agentes que continúan tras cerrar sesión

Objetivo

Estado a 25 de octubre de 2026. Definir qué puede hacer un agente después de que su operador se desconecte, cuánto puede consumir y cómo termina su autoridad. Volver a comprobar el comportamiento de reinicio del supervisor desplegado, el ciclo de vida de las credenciales y la compatibilidad con la cancelación remota. Este contrato propuesto complementa la configuración de la cuenta de servicio con controles sobre toda una ejecución sin supervisión.

Requisitos previos

Designar un responsable, un almacén persistente de tareas y un supervisor capaz de detener el trabajo con independencia del modelo. Inventariar los procesos locales, los subagentes delegados y los trabajos remotos. A diferencia de una sesión interactiva, este flujo necesita una respuesta definida cuando no se pueden obtener aclaraciones: guardar de forma persistente un estado de bloqueo y notificar a la persona responsable por un canal aprobado.

Pasos

1. Registrar el contrato de ejecución. Guardar la revisión del objetivo, los recursos y las acciones permitidos, la ubicación de salida, el vencimiento, el presupuesto y la vía de escalamiento. Dar al servicio una identidad propia restringida y registrar por separado al usuario que lo inició. No utilizar una copia del almacén de credenciales de una sesión interactiva como configuración de identidad del servicio.
2. Conceder únicamente el acceso necesario. Utilizar los mecanismos de identidad para cargas de trabajo de la plataforma. La documentación de cuentas de servicio de Kubernetes describe identidades diferenciadas para las cargas de trabajo y automountServiceAccountToken: false para los Pods que no deban recibir credenciales de API montadas automáticamente. Aplicar permisos acotados en el recurso al que se accede. La renovación de credenciales no debe ampliar de forma implícita el período de autorización de la tarea.
3. Presupuestar la tarea completa. Conservar de forma persistente el gasto acumulado entre subagentes, reintentos y reinicios de procesos. Definir límites para el tiempo transcurrido, las llamadas al modelo y a las herramientas, la concurrencia, el almacenamiento y los servicios facturables. Reservar capacidad antes de despachar trabajo cuando los trabajadores concurrentes puedan superar una asignación compartida. Documentar qué límites aplica realmente el supervisor o la pasarela; una frase en el prompt es solo una petición.
4. Crear una vía de parada independiente. Al vencer la autorización o cuando el operador ordene detener la ejecución, bloquear nuevos despachos, desactivar el reinicio automático de esa ejecución y solicitar la cancelación del trabajo registrado. Hacer cumplir el vencimiento de la autorización en la pasarela de escritura cuando esté disponible. Conciliar las operaciones ya aceptadas de forma remota antes de informar de que la parada ha finalizado. Mantener visibles los efectos sin resolver e impedir la repetición a ciegas tras un reinicio.
5. Precisar la función de los controles de la plataforma. Los Jobs de Kubernetes admiten activeDeadlineSeconds y la suspensión. Suspender un Job termina sus Pods activos; reanudarlo reinicia el temporizador del plazo de actividad. Por tanto, conservar un vencimiento absoluto de la autorización fuera de ese temporizador. Considerar la suspensión como un control del ciclo de vida de los procesos, que requiere puntos de control persistentes de la aplicación para la recuperación, y verificar por separado los resultados remotos.
6. Permitir la inspección del estado sin supervisión. Registrar los identificadores de tarea e intento, la revisión del objetivo, la referencia de identidad, el consumo de presupuesto, el resultado de la herramienta y el motivo de parada, sin secretos. La propagación de contexto de OpenTelemetry proporciona correlación de trazas entre servicios. Exportar los registros necesarios antes de limpiar la carga de trabajo. Para un Job de Kubernetes, kubectl get job JOB -o yaml muestra su estado registrado; kubectl logs jobs/JOB es un punto de partida para inspeccionar la salida, no un historial completo de todos los intentos.

Resultado esperado

Un operador desconectado puede determinar quién autorizó una ejecución, qué sigue activo y si todavía tiene autoridad para escribir. El reinicio del trabajador conserva el presupuesto restante y el vencimiento original. Siguen siendo distinguibles la finalización, la espera de información, la parada en curso y los resultados remotos sin resolver.

Límites y base de verificación

Este es un procedimiento propuesto, no un despliegue probado. En un entorno aislado, probar la desconexión del operador, el agotamiento de la cuota, el reinicio y el vencimiento mientras está pendiente una operación remota simulada. Comprobar que no se admite ninguna acción nueva después de alcanzar el límite y que los efectos pendientes siguen registrados. La terminación de un proceso no puede servir de prueba de que se haya deshecho una acción remota.