| Internet-Draft | Agent Operation Continuity | September 2026 |
| Schrock | Expires 19 March 2027 | [Page] |
An agent executor can fail or be replaced after a consequential provider request may have crossed an effect boundary but before the outcome is known. Native authorization, succession, evidence-boundary, and bounded-capability mechanisms address parts of this interval, but they do not by themselves define how a replacement executor preserves the same provider operation and its unresolved evidence.¶
This document defines a composition profile for one authoritative coordination domain. The profile preserves stable operation-occurrence identity, immutable provider bindings, authority accounting, uncertain evidence, and stale-executor fences across replacement. It defines no new receipt, identity, authority, provider, or ledger-migration format, and it does not require any particular evidence envelope.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
A worker may submit a consequential request to a payment, messaging, infrastructure, or other effecting provider and then fail before it can persist the provider's response. Replacing that worker does not make the earlier request disappear. A successor that treats the work as fresh can duplicate the effect, while a successor that discards the work can lose an unresolved obligation.¶
Several native mechanisms provide relevant pieces. AADP [AADP] provides durable per-action authorization intent, decision and report idempotency, and an attempted/result-unknown report. Succession Receipts [SUCCESSION] can record a completed predecessor-to-successor transition and carried commitments. AEB [AEB] separates provider entry from effect outcome and requires authenticated reconciliation. Bounded Capability Receipts [BCR] define durable reservation, provider-entry accounting, replay tombstones, and an admission epoch.¶
This document specifies the missing composition contract: preserve one provider-operation occurrence and its evidence across replacement without restoring spent authority, resetting provider keys, or inventing a favorable outcome. The contract is deliberately bounded to one authoritative coordination domain and its covered provider paths.¶
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
provider_entered transition that moves reserved authority to
consumed before adapter invocation.¶
This profile covers one authoritative coordination domain that serializes admission for a protected provider path. The domain admits or refuses each covered occurrence and preserves it when the worker executor is replaced.¶
The profile assumes that every covered executor uses the coordination boundary before provider entry; that the deployment pins a provider profile, account or environment, exact request representation, native key and reference rules, status sources, and retention expectations; and that each native authority mechanism retains its own accounting and replay semantics.¶
The profile does not make an uncovered credential path safe. An implementation MUST disclose direct, administrator, break-glass, queued, alternate-protocol, and system-of-record paths that bypass the coordination domain.¶
This document does not define a universal customer, job, responsibility, task, action-digest, agent, or worker identifier; a new succession or authorization receipt; a portable authority ledger; a universal provider key or outcome vocabulary; payment, refund, compensation, reputation, or acceptance semantics; a mandatory evidence format; or equivalence between native identifiers or verdicts.¶
For every covered operation occurrence, an implementation MUST identify one authoritative coordination domain that serializes reservation, provider-entry admission, executor-generation changes, and terminal reconciliation. A profile instance MUST NOT claim exclusive admission control beyond paths mediated by that domain.¶
The coordination domain MUST select or assign a stable operation-occurrence identifier before provider entry and MUST retain it through executor replacement and terminal reconciliation. An implementation MAY use an existing native operation identifier, such as a BCR operation identifier, when it is stable, occurrence-specific, and replay-protected under the selected native profile. This document does not define a new universal identifier.¶
The coordination domain MUST own the occurrence-creation rule or validate it against a pinned authoritative system of record. It MUST either resolve a stable system-of-record occurrence reference or atomically mint a new occurrence only after local policy determines that the request is a distinct intended occurrence. Creation retries MUST use a durable occurrence-creation binding and return the original occurrence. A caller-supplied business occurrence identifier MAY be used when the coordination boundary authenticates it and validates its uniqueness and semantics under that rule. A caller-selected relabel, grant, task, or retry ID MUST NOT by itself establish a new occurrence.¶
The occurrence identifier MUST NOT be an authority grant identifier, reusable task identifier, or action digest. A caller retry identifier MAY map to the occurrence only after the coordination boundary resolves it under the durable occurrence-creation binding. Identical action digests MAY represent separate legitimate occurrences when the occurrence-creation rule and local policy distinguish them. A deployment requiring at most one occurrence for a material action MUST use a durable action fence or bind the unique occurrence into the material action under its pinned definition; it MUST NOT silently treat an action digest as an occurrence identifier.¶
An implementation MAY map AADP request_id,
AADP permit_id, a Succession Receipt identifier, BCR
operation_id, a provider-native key, and a provider operation
reference to the occurrence, but MUST retain their types
and native meanings and MUST NOT claim semantic
equivalence merely because values are stored together or carry equal
text.¶
Before provider entry, the coordination domain MUST durably bind the occurrence to all of the following:¶
Every later admission, status query, response, or reconciliation transition MUST match this binding. An implementation MUST NOT rebind the occurrence to another profile, account, request, native key, or provider reference to escape an unresolved or terminal state.¶
The coordination domain MUST preserve an append-only history sufficient to distinguish preparation with no serialized provider entry; serialized provider entry without authoritative acknowledgement; provider acknowledgement or native reference; each provider-status observation with source, time, and profile interpretation; and the terminal reconciliation decision with its evidence binding.¶
An implementation MAY use different local state labels. It MUST NOT overwrite a prior observation in a way that hides provider entry, uncertainty, a retired executor, a conflicting observation, or a prior terminal decision.¶
Replacing an executor MUST NOT change the occurrence identifier, discard its provider binding or attempt evidence, clear its unresolved state, replenish or recreate its authority, or authorize another provider attempt. The successor MUST receive, or be able to query, the current occurrence state and its unresolved evidence before it can act on that occurrence.¶
The coordination domain MUST advance the executor generation and retire the predecessor before admitting new work for the successor. Reservation and provider-entry transactions MUST compare the current generation with the generation captured for the pending attempt.¶
A retired executor MUST NOT create a new reservation, enter the provider, replace the native provider key, or claim a new attempt. The deployment MUST define finite limits for pending and in-flight occurrences so executor failure cannot create unbounded held state. Fencing inside the coordination domain MUST NOT be described as revoking credentials or stopping paths outside that domain.¶
An authenticated provider response received after executor replacement MAY be accepted when it matches the immutable provider binding and the exact predecessor attempt. Accepting that response MUST NOT reactivate the retired executor, create a new admission, extend authority, or authorize replay. A response that cannot be bound to the exact prior attempt MUST leave the occurrence unresolved.¶
Held pre-entry authority MAY be released only when the authoritative coordination domain serially establishes that provider entry did not occur while the operation remains in its pre-entry reservation state. The release transition MUST authenticate the reservation owner, match the occurrence and exact request binding, be atomic with the authority adjustment, and retain a terminal replay tombstone.¶
This requirement governs the AOC/provider-occurrence exposure and any native authority reservation whose profile makes release depend on provider non-entry. It does not suppress a distinct AADP-native permit-reservation expiry transition; the accounting separation and unsupported-alias rule are stated in Section 5.¶
Deadline expiry, executor death, absence of a provider response, an unrecognized provider reference, or an unauthenticated provider claim MUST NOT by itself establish non-entry. A later presentation of the same occurrence or native key MUST NOT create a new reservation.¶
Each provider profile MUST identify all of the following:¶
accepted,
not_accepted, final_failure, and
success; and¶
The implementation MUST preserve the native response and profile interpretation separately. It MUST NOT infer a terminal result from HTTP class, transport completion, absence from a non-complete listing, local exception text, elapsed time, or a provider label that the pinned profile does not define.¶
Once an occurrence has a provider binding, a request to change the provider account, exact request, profile version, native key, or provider reference MUST be rejected as a conflicting operation. A request with the same occurrence-creation binding MUST resolve to the existing occurrence. Creating a new caller-selected operation identifier, grant, task, action digest, occurrence identifier, or executor generation MUST NOT bypass this refusal.¶
An unresolved or terminal occurrence MUST NOT enter the provider again. A provider-native idempotency key is a defense at the provider boundary, not permission for the coordination domain to admit a second attempt.¶
The following terms are profile-level interpretations, not universal provider states:¶
acceptednot_acceptedfinal_failuresuccessUnknown, pending, stale, incomplete, conflicting, or unmapped native states MUST leave the occurrence unresolved.¶
When the native authority profile consumes or commits authority at
provider entry, later not_accepted, final_failure,
compensation, reversal, refund, or other remedy evidence
MUST NOT restore, erase, or relabel the original consumed
authority merely because the protected effect failed or was
compensated.¶
A provider-specific terminal no-effect result MAY resolve outcome uncertainty, but it does not imply an accounting refund under every authority policy. Any later adjustment, replacement attempt, compensation, or new allocation MUST be separately authorized under its governing native policy, linked to the original occurrence, and assigned its own replay-protected operation identity. The original occurrence identity, provider binding, consumed-authority record, and prior history entries MUST remain immutable. Authenticated reconciliation evidence and separately authorized adjustments MAY be appended without rewriting those facts.¶
This profile MUST NOT be used to claim that copying an operation record transfers exclusive ownership of a live ledger, that a Succession Receipt fences a provider path, that AADP and BCR state machines are interchangeable, or that any EP evidence format is mandatory. A cross-domain ledger migration requires a separately specified exclusive cutover protocol and is outside this profile.¶
This profile relies on, but does not amend, AADP-02 Sections 4 and 7
for durable intent, decision and report idempotency, the
timeout report for attempted/result-unknown, and the prohibition
on blind retry; Succession Receipts-02 for evidence of a completed
predecessor-to-successor registry transition and carried commitments;
AEB-05 Sections 5.8 through 5.11 for atomic consumption or reservation,
dispatch intent, outcome separation, and authenticated reconciliation;
and BCR-06 Sections 10 and 11.1 for provider-entry accounting, replay
tombstones, crash recovery, and admission epochs.¶
AADP's request_id remains a decision-idempotency key and its
permit_id remains a single-use permit/report identity. A
Succession Receipt remains evidence of an issuer-recorded completed
transition. AEB's effect states remain native AEB states. BCR's
capability-scoped operation_id and provider-entry accounting
remain native BCR semantics. Storing these values with one occurrence
does not make them wire-compatible or semantically equivalent.¶
AADP-02 Section 4 natively requires the PDP to append an expiry event
and release its permit reservation when execute_within passes
without a report. AADP timeout remains the native report outcome
when a report is made for attempted/result-unknown; no-report expiry is a
distinct transition. AOC does not amend or suppress the AADP expiry
transition.¶
In a composed deployment, the AADP permit reservation and the AOC/provider-occurrence exposure MUST be represented as distinct native accounting facts unless another specification defines their joint state machine. AADP expiry MAY release only the AADP-native permit reservation; it MUST NOT erase the AOC occurrence tombstone, relabel serialized provider entry as non-entry, restore BCR allowance already consumed at provider entry, or authorize another attempt for that occurrence.¶
If an implementation aliases the AADP reservation to the same counter
AOC/BCR requires held or consumed after provider entry, it cannot claim
simultaneous conformance to both contradictory transitions and
MUST report the composition unsupported. The AOC occurrence
remains unresolved until its provider-entry and effect evidence meet this
profile. This is a source-level composition tension, not a tested
onedoor defect, and AOC does not invent an AADP verdict.¶
No EP, AADP, Succession Receipt, AEB, BCR, provider-native, or local evidence format is mandatory. Verification of an artifact proves only that artifact's native claims under its pinned trust rules.¶
A provider mapping satisfies this profile only when it pins provider identity, account or tenant, environment, API or profile version, authenticated status sources, exact request representation, native key derivation, reference-creation semantics, native status meanings, terminality, no-effect meaning, retention and freshness horizons, completeness and pagination guarantees, and the evidence needed to bind a result to the occurrence.¶
A result outside those exact mappings is missing knowledge. In
particular, generic FAILED is not proof of non-entry or no
protected effect. A profile may define an authenticated provider result
equivalent to NO_EFFECT_CONFIRMED, but even that result does not
rewind provider entry or automatically restore authority.¶
A conforming implementation MUST satisfy every requirement from AOC-REQ-001 through AOC-REQ-013 and pass every case in this section under its declared provider profile. It MUST report unsupported cases, missing status knowledge, bypass paths, and untested provider semantics rather than treating them as passes.¶
A report MUST identify the implementation and provider profile versions, test-input digest, occurrence identifier, executor generation, provider-binding digest, terminal or unresolved state, provider-entry and authority-accounting state, provider-entry attempt count, evidence-source and missing-knowledge flags, case results, and requirement IDs evaluated. It MUST NOT expose credentials, reservation tokens, or private provider requests.¶
A same-team model or runner MUST be labeled as such. Passing abstract local cases establishes consistency with the profile, not independent interoperability, live-provider correctness, deployment, or adoption. Independent interoperability requires at least two independently maintained implementations to exercise locked cases with an agreed provider profile and compare observable decisions.¶
The principal security failures addressed by this profile are duplicate provider effects after worker replacement, authority restoration after provider entry, stale-executor admission, provider-key rebinding, loss or rewriting of uncertain evidence, and false terminal conclusions from incomplete status sources.¶
The coordination boundary is a security-critical serialized state owner. Implementations need atomic durability for occurrence creation, reservation, provider entry, generation changes, pre-entry release, and terminal reconciliation. If an attacker can roll back or fork that state, the profile cannot prevent double admission.¶
Provider responses and status sources need authentication and binding to the exact provider profile, account, environment, request, native key, and reference. A valid response for another account or request is not evidence for the occurrence. Clock, retention, completeness, and pagination assumptions are part of the provider profile and cannot be inferred from transport success.¶
An admission epoch fences only transactions mediated by the declared coordination domain. It does not recall a request already admitted to the provider and does not revoke credentials or stop direct, queued, administrator, or alternate-protocol paths. Those paths need separate controls and disclosure.¶
A malicious caller may relabel a retry as a fresh occurrence. The coordination boundary therefore owns or authoritatively validates the occurrence-creation rule. Conversely, equal action digests are not enough to collapse two legitimate repeated operations; deployments requiring material-action uniqueness need the explicit action fence in Section 4.2.¶
Provider entry and protected-effect outcome are distinct. Failure, compensation, refund, or a provider-specific no-effect result cannot silently restore authority already consumed at entry. A separate remedy requires separate authorization and replay protection.¶
This section records implementation information in the spirit of [RFC7942] and is intended for removal before publication as an RFC.¶
A same-team local model and synthetic provider runner exercise the
thirteen requirement identifiers and twelve conformance cases in this
draft. The runner is bounded evidence of the model's behavior only. It
does not execute the AADP onedoor implementation, a live provider
API, a production authorization boundary, or an independently maintained
implementation. Its results therefore do not establish full native
protocol conformance, independent interoperability, deployment, adoption,
or provider truth. The implementation report identifies unsupported and
synthetic boundaries rather than treating them as externally verified.¶
Continuity records may link customer or tenant accounts, worker generations, exact request digests, provider references, timestamps, outcomes, and remedies over long periods. That correlation can expose commercial relationships, operational schedules, and sensitive activity. Implementations should minimize retained plaintext, separate access to provider requests from access to coordination metadata, and apply purpose-limited authorization and audit to status and history queries.¶
Retention cannot be shortened below the interval needed to prevent replay or reconcile provider uncertainty merely for convenience. A deployment should document the retention basis, deletion constraints, cryptographic key lifecycle, and whether redaction leaves enough durable binding to reject replay without retaining unnecessary content.¶
Conformance reports must not disclose bearer credentials, reservation tokens, or raw private provider requests. Digests may still enable guessing of low-entropy data and therefore require an appropriate canonicalization and confidentiality policy.¶
This document has no IANA actions.¶