Continuity Without Unbounded Autonomy

Abstract

Long-running AI work can be governed by either of two unsafe simplifications. A worker stops when its timer, process or retry budget ends and the system quietly treats the requested outcome as abandoned; or the worker keeps renewing itself because the outcome remains unfinished, turning continuity into indefinite authority and consumption. This paper proposes a bounded-continuity model that separates five objects: the requested outcome, delivery forecast, execution attempt, authority envelope and dependency state. An attempt is always finite. Its expiry cannot prove that the outcome was achieved or cancelled, but neither may the attempt create its own successor. At each boundary, a controller or accountable human closes the attempt, preserves evidence and makes an explicit transition: complete, wait, block, stop, or admit a separately bounded successor after rechecking authority, resources and meaningful progress. The design draws on AI risk-governance guidance, distributed-system retry controls, finite job-controller semantics, a recent normative analysis of agent autonomy and a limited first-party design record. It is a proposal to evaluate, not evidence that automatic recovery is installed or universally beneficial. A companion protocol supplies a state model, boundary receipt, admission test and failure-injection cases.

1. Research question and scope

How can an AI system preserve responsibility for an unfinished outcome across finite execution attempts without giving any worker indefinite permission to act or retry?

The question matters whenever work outlives one model call, process, shift, browser session or scheduled run. Examples include investigations, multi-stage document production, software changes awaiting tests, and operations waiting for an external state change. In each case, a useful system must carry context and ownership forward. Yet persistence alone is not enough: credentials may expire, budgets may be exhausted, instructions may change, dependencies may become non-retriable, and repeated attempts may stop producing information.

This paper concerns the control plane around such work. It does not propose that every chat request become a durable workflow, that agents should operate without supervision, or that a missed deadline is harmless. It also does not present an exercised autonomous scheduler. Its contribution is a temporal contract: preserve the obligation as a record, but grant execution only through finite, separately admitted attempts.

2. Method and evidence boundary

The method is evidence-informed architectural synthesis. We compared four adjacent bodies of practice and derived a lifecycle that keeps their distinctions visible.

NIST's AI Risk Management Framework treats governance as continuous across the AI lifecycle. It calls for explicit responsibilities, ongoing monitoring and review, recovery procedures, and mechanisms to supersede, disengage or deactivate systems whose outcomes conflict with intended use [1]. This supports accountable lifecycle management, but does not prescribe an outcome/attempt contract.

AWS reliability guidance recommends that retries have backoff, jitter and a maximum, warns against retrying permission and configuration failures, and notes that retries at multiple layers can multiply load [2]. Kubernetes Jobs similarly separate a job's recorded state from individual Pods while exposing backoffLimit and activeDeadlineSeconds as finite execution controls [3]. These sources show mature finite-attempt mechanics; they do not decide whether a human's broader objective should remain open.

Mitchell and colleagues describe levels of agent autonomy in which progressively more control over iteration and execution moves from humans to systems. Their normative preprint argues against full autonomy and for retaining human control [4]. We use it as a caution about self-directed continuation, not as empirical proof of this proposal.

Finally, a first-party design record explicitly distinguishes outcome, forecast, attempt and hard authority/resource limits [5]. It is useful prototype doctrine, but non-independent and not evidence that automatic continuation has been implemented. The model below is therefore a testable synthesis. Its effectiveness, cost and failure rates remain to be measured.

3. Five objects that should not share one clock

3.1 Outcome

The outcome is the bounded result requested: for example, “produce six reviewable working papers” or “verify that the named record reached the expected state.” It has identity, scope, acceptance criteria, an accountable owner and a terminal decision. It can be open even when nothing is currently executing.

An outcome is not immortal. It terminates when it is verified complete, explicitly cancelled or superseded, or closed by an authorised decision because a genuine boundary makes it no longer permissible or useful. What it should not do is disappear merely because an implementation estimate was wrong.

3.2 Forecast

A forecast predicts when the outcome or a milestone may be delivered. Missing it is operationally meaningful: the system should disclose the miss, update the forecast and reconsider its method. But a forecast is descriptive unless the requester explicitly made the time a work-only window or other hard condition. Quietly converting “expected by 15:00” into “permission ends at 15:00” confuses planning with authority.

3.3 Attempt

An attempt is one finite execution tranche: a model invocation, worker lease, scheduled run, tool session or human shift. It needs a start, deadline or budget, expected delta, allowed effects and immutable evidence. Attempts should terminate predictably. Kubernetes' distinction between a Job and replacement Pods is an instructive engineering analogy: a controller can preserve job state while bounding retries and total active duration [3]. The analogy stops at infrastructure; a business outcome needs richer acceptance and authority semantics.

3.4 Authority envelope

The authority envelope states what may be done now: actor, principal, operations, resources, side effects, approvals, budget and expiry. An open outcome does not extend an expired grant. A successor attempt requires current authority, and no worker may create that authority for itself. This paper complements task-scoped authorization rather than replacing it.

3.5 Dependency state

A dependency explains why useful progress cannot currently occur and what would make it possible: a provider response, human decision, resource release, test environment or time-delayed state change. “Waiting” without a named owner, observable condition and next review is merely forgotten work with a respectable label.

Separating these objects permits a precise statement:

open outcome ≠ active attempt ≠ current authority
forecast miss ≠ cancellation
attempt expiry ≠ permission to renew

4. The bounded-continuity lifecycle

The proposed outcome lifecycle contains seven states:

1. Proposed — scope and acceptance criteria are not yet admitted.
2. Ready — outcome is authorised and prerequisites for an attempt are satisfied.
3. Running — exactly identified finite attempt(s) are active under current grants.
4. Waiting — no useful independent work can proceed; dependency owner and wake condition are recorded.
5. Blocked — a safety, authority, resource or unresolved decision boundary prevents continuation.
6. Stopped — an authorised stop, cancellation or supersession ends the obligation.
7. Verified complete — acceptance evidence proves the requested outcome, not merely that an attempt returned success.

Running is not a terminal success state. Nor are Waiting and Blocked euphemisms for completion. A dependency can move from waiting to ready when its observable condition is met. A block moves only through a new authoritative or environmental fact; retrying the same action does not dissolve it.

Every attempt has its own smaller lifecycle: admitted → running → succeeded | failed | expired | contained. “Succeeded” means the attempt produced its promised delta, not necessarily that the outcome is complete. “Contained” means processes and side effects have stopped or been accounted for before another attempt begins.

5. The boundary protocol

At the end of every attempt, the controller writes a boundary receipt before admitting a successor. The receipt should answer:

• Which outcome and attempt IDs were active?
• What exact progress was made, and what evidence supports it?
• Which acceptance criteria remain unmet?
• Are any processes, locks, temporary grants or side effects still live?
• Did authority, requester intent, target identity or policy change?
• Is protected resource headroom still available?
• Is the next action retry-safe and, if mutating, idempotent or otherwise deduplicated?
• Did this attempt reduce uncertainty or produce a durable delta?
• Who owns the next decision, and what condition should wake it?

A successor is admitted only if the prior attempt is contained, scope remains unchanged, current authority covers the proposed actions, resources satisfy protected reserves, and the next method has a credible information gain or deliverable. It receives a new execution identity and finite budget while remaining attached to the same outcome.

This is deliberately asymmetric. Workers may report that more work is needed; they may not infer a new grant from that fact. Parent or control-plane admission prevents a process from translating its own incompleteness into continuing power.

6. Retry is only one form of continuation

Repeated execution is appropriate for transient failure, not for every incomplete state. AWS identifies permission and configuration errors as conditions that predictably require intervention and warns that layered retries can create retry storms [2]. For agentic workflows, the same principle should be applied semantically:

• Retry when the failure is classified as transient, the action is safe to repeat and the bounded policy permits another attempt.
• Change method when the attempt ran but did not reduce uncertainty or repeatedly hit the same defect.
• Wait when an external event is necessary and observable.
• Escalate when judgement, approval or policy change is required.
• Stop when explicitly directed, when authority is revoked, or when safety cannot be maintained.

A retry counter alone cannot make this decision. It can enforce a ceiling, but classification and ownership determine what happens after the ceiling. The outcome record may remain open while automated execution stops.

7. Failure modes the model prevents

Timer-as-cancellation. A worker expires and the orchestration layer marks the entire job done or silently drops it. The proposed model instead closes only the attempt and leaves an explicit outcome state.

Immortal worker. A process renews itself because acceptance criteria remain unmet. The model denies self-admission and requires a new bounded grant.

Zombie authority. A stored task is resumed with credentials or approvals from an earlier context. The boundary check resolves current authority rather than reviving historical access.

Retry storm. Multiple layers each retry, multiplying cost or side effects. One controller owns the attempt policy; retry counts and idempotency evidence are visible [2].

Ownerless waiting. The record says “pending” but contains no owner, wake condition or review time. The waiting transition is invalid until those fields exist.

Narrative progress. Repeated reports consume budget without creating evidence, artifacts or reduced uncertainty. A non-progress counter forces method review or blocking instead of rhetorical continuation.

False completion. A successful worker exit is treated as proof of the business outcome. Outcome acceptance remains a separate, evidence-based transition.

8. Alternatives and trade-offs

Single long-lived agents minimise handoff cost and preserve rich context. They also concentrate credentials, make resource drift harder to bound and blur when authority was last checked. They may suit low-risk contained environments, but should still expose stop and review boundaries.

Fire-and-forget tasks are simple and cheap. They are appropriate where partial work has no continuing obligation. For accepted multi-stage outcomes, however, process exit becomes an unreliable proxy for cancellation or completion.

Durable workflow engines can persist state, timers and retries. They are strong implementation substrates, but do not by themselves distinguish a forecast from authority, decide whether work remains worth doing, or supply human acceptance criteria. A badly specified durable workflow can preserve the wrong obligation very efficiently.

Human approval at every boundary provides strong control but can create latency and approval fatigue. A better design reserves human judgement for consequential, ambiguous or authority-changing transitions while allowing policy to admit low-risk, unchanged continuations.

The principal cost of bounded continuity is control-plane complexity: state storage, receipts, containment checks, grant refresh, dependency ownership and deduplication. Too much ceremony can make short tasks slower. The protocol should therefore scale with duration, consequence and uncertainty rather than with the fashionable presence of the word “agent.”

9. Practical application

The accompanying protocol provides an outcome card, attempt contract, boundary receipt, admission decision and failure-injection suite. A useful pilot should choose one multi-stage workflow with observable acceptance criteria and a known external dependency.

Consider a synthetic document review. The outcome is “deliver a six-document pack accepted against a checklist.” Attempt A has 20 minutes and may write only documents 1–2. It completes document 1 and expires midway through document 2. The correct state is not complete and not uncontrolled continuation. Attempt A is contained; evidence and hashes are recorded; the outcome returns to Ready; a controller checks unchanged scope, current authority and storage headroom, then may admit Attempt B with a new identity. If the owner revokes access before B, the outcome becomes Blocked or Stopped according to the owner's decision. If B repeats the same parsing failure without new information, the next transition is method review—not Attempt C by reflex. These transitions are illustrative and were not executed as an experiment.

10. Limitations and evaluation agenda

This paper presents no comparative field trial, formal liveness proof or production scheduler. NIST supplies broad governance outcomes, not this state machine [1]. AWS and Kubernetes document engineering controls in their own platforms, not AI task semantics [2,3]. Mitchell et al. provide a normative analysis of autonomy, not measured evidence for bounded continuation [4]. The first-party record is doctrine and may reflect local operating preferences [5].

The model can still fail if state is lost, two controllers admit successors concurrently, identity resolution is wrong, a worker cannot be contained, dependencies are misclassified, or acceptance criteria are vague. Parent admission can become a bottleneck. Frequent handoffs can lose tacit context. An attacker may forge progress evidence or manipulate a wake condition. Resource checks can become stale between decision and execution.

Evaluation should compare a single long-lived worker, fixed-stop execution and bounded continuation on matched workflows. Measures should include accepted-outcome rate, unauthorized continuations, abandoned open outcomes, duplicate side effects, resource consumption, time past forecast, handoff loss, false blocking, operator interventions and non-progress attempts. Fault injection should cover expiry, revocation, budget exhaustion, dependency delay, stale state, concurrent admission, controller crash and contradictory instructions. Until those tests exist, the proposal should be treated as a structured hypothesis.

11. Conclusion

Continuity and autonomy are not synonyms. A system can retain an obligation without retaining a running process, and it can preserve context without preserving permission. The essential design move is to keep the outcome durable while making every execution attempt, authority envelope and retry budget finite.

At each boundary, evidence replaces optimism: contain the old attempt, state what remains, classify the dependency, recheck authority and resources, and admit only a bounded next step that can plausibly add value. This avoids both familiar extremes—quiet abandonment and endless self-renewal. It does not make autonomy safe by declaration. It makes continuation an explicit, testable decision.

References

1. National Institute of Standards and Technology. AI Risk Management Framework 1.0: AI RMF Core. 2023. https://airc.nist.gov/airmf-resources/airmf/5-sec-core
2. Amazon Web Services. REL05-BP03 Control and limit retry calls. AWS Well-Architected Framework, undated. https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_limit_retries.html
3. The Kubernetes Authors. Jobs. Kubernetes Documentation. https://kubernetes.io/docs/concepts/workloads/controllers/job
4. Margaret Mitchell, Avijit Ghosh, Alexandra Sasha Luccioni and Giada Pistilli. Fully Autonomous AI Agents Should Not be Developed. arXiv:2502.02649. https://arxiv.org/abs/2502.02649
5. Nordlith. Mission Outcome Supremacy. Revision 2, 9 October 2026. First-party design record; no claim of automatic scheduler implementation or independent validation.