Defining an execution contract for agents that continue after logout

Goal

Status as of 25 October 2026. Define what an agent may do after its operator disconnects, how much it may consume and how its authority ends. Re-check the deployed supervisor's restart behavior, credential lifecycle and remote cancellation support. This proposed contract supplements service-account configuration with controls over an entire unattended run.

Prerequisites

Name an accountable owner, a durable task store and a supervisor that can stop work independently of the model. Inventory local processes, delegated children and remote jobs. Unlike an interactive session, this workflow needs a defined response when clarification is unavailable: persist a blocked state and notify the responsible person through an approved channel.

Steps

1. Record the execution contract. Store the objective revision, permitted resources and actions, output location, expiry, budget and escalation route. Give the service its own restricted identity and record the initiating user separately. Do not make a copied interactive credential store the service's identity configuration.
2. Grant only the required access. Use the platform's workload identity facilities. Kubernetes service-account documentation describes distinct workload identities and automountServiceAccountToken: false for Pods that should not receive automatically mounted API credentials. Apply narrow permissions at the resource being accessed. Credential refresh must not silently extend the task's authorization window.
3. Budget the whole task. Persist cumulative expenditure across children, retries and process restarts. Define limits for elapsed time, model and tool calls, concurrency, storage and billable services. Reserve capacity before dispatch where concurrent workers could overspend a shared allowance. Document which limits the supervisor or gateway actually enforces; a sentence in the prompt is only a request.
4. Build an independent stop path. On expiry or an operator stop, block new dispatch, disable automatic restart for that run and request cancellation of tracked work. Enforce authorization expiry at the write gateway where available. Reconcile operations already accepted remotely before reporting a completed stop. Keep unresolved effects visible and prevent blind replay after restart.
5. Map platform controls precisely. Kubernetes Jobs support activeDeadlineSeconds and suspension. Suspending a Job terminates its active Pods; resuming resets the active-deadline timer. Therefore retain an absolute authorization expiry outside that timer. Treat suspension as process lifecycle control, with durable application checkpoints required for recovery, and verify remote outcomes separately.
6. Make unattended status inspectable. Record task and attempt identifiers, objective revision, identity reference, budget use, tool outcome and stop reason without secrets. OpenTelemetry context propagation provides trace correlation across services. Export necessary logs before workload cleanup. For a Kubernetes Job, kubectl get job JOB -o yaml shows its recorded state; kubectl logs jobs/JOB is a starting point for output inspection, not a complete history of every attempt.

Expected result

A disconnected operator can determine who authorized a run, what remains active and whether it still has authority to write. Restarting the worker retains the remaining budget and the original expiry. Completion, waiting for input, stopping and unresolved remote outcomes remain distinguishable.

Limits and test basis

This is a proposed procedure, not a tested deployment. In an isolated environment, exercise operator disconnect, quota exhaustion, restart and expiry while a fake remote operation is pending. Check that no new action is admitted after the boundary and that pending effects remain recorded. Process termination cannot serve as evidence that a remote action was undone.